How I can create users in Subversion.
For when people access the repository, only to see their projects or files and not those of the other people?
Answer depends on how Subversion server is setup.
If you're using httpd then it depends on how authentication is setup in httpd. See SVNBook | Authentication options.
If you're using svnserve then you can use the built in authentication setup.
And if you're using svn+ssh:// then either users log into ssh as their own user (in which case how to add users is a function of adding users to ssh) or they log into as a shared user and the --tunnel-user argument gets set.
Related
Our Perforce server is set to security level 0, meaning that most users don't require passwords. This is fine (and necessary for our legacy tools). However I recently discovered to my horror that some admin user accounts don't have passwords set. This is obviously very bad.
How can we configure Perforce to require passwords for superuser accounts, but not for regular accounts?
I seem to remember this was the case by default, but someone seems to have defeated it, and now I can't find any mention of it in the Perforce manual.
We cannot change the server to require passwords from all users without breaking the whole company. Setting the server security level to >1 globally is not a workable answer.
Nope, this was never a feature.
My solution to this has historically been to have a script that tries to run a command as each user. In your case you want to only look at users with admin-level permissions, so have the script run a command that only admins should be able to run:
p4 -u $USER protect -o
If this succeeds (despite the lack of any password being provided), deal with them as you like. In my case I wasn't targeting admin users specifically so I just had my script set a random password and email it to them with instructions for changing it.
Given your scenario, my recommendation would be to just revoke admin access, since someone who's not savvy enough to secure their own account probably shouldn't be trusted with the ability to grant access to others, install triggers, permanently delete data, etc...
I am attempting to integrate a standalone product into an LDAP environment.
I have a RHEL 6.7 system that is configured for ldap authentication (via sss) that I need to programmatically add local users and groups to.
The input xml file has a list of users and groups with their group membership, login shell, user id and group id that should be used.
Now comes the problem, I have a Perl script that uses the XML file to configure the users and groups, it uses the getgrnam and getpwnam to query for users and groups then makes a system call to groupmod/groupadd and usermod/useradd if the user exists or not. I found that if LDAP has a group the same name as the group I am trying to create my script will see the group as existing and jump to the groupmod instead of groupadd. Then group binaries will only perform operations on local groups, and fail because the group doesn't exist locally. NSS is setup to check files then sss, which make sense why getgrnam returns the ldap group.
Is there a way to have getgrnam and getpwnam only query the local system without having to reconfigure nsswitch.conf and possibly stop/start SSSD when I run the script?
Is there another perl function I can use to query only local users/groups?
Short answer is no - the purpose of those function calls is to make the authentication mechanisms transparent. There's a variety of things you could be using, and no one wants to hand roll their own local files/ldap/yp/nis+/arbitrary PAM authentication mechanism.
If you're specifically interested in the contents of the local passwd and group files, I'd suggest the answer is - read those directly.
My campus runs a gitlab server. I am a user, not an admin. Campus policy forbids giving LDAP access to off-campus collaborators/co-authors, but has no problem in principle with allowing such folks to have "Developer" level access to non-public repositories on an invitational basis. Is it possible to have my off-campus colleagues send me an SSH key, and have the gitlab admin create a no-login user with that key who I could then add as a "Developer" member to selected projects? If it's do-able, what's the magic process so I can pass it along to the IT support folks?
Ask your IT support team to create Gitlab account with specific permissions for those developers without LDAP account. And then simply add them to the repositories and ask them to upload ssh keys.
I have a sudo account (not root) on several CentOS servers. We would like to share the cluster with other uses who do not have an account for research purpose. (By share I mean users can reserve a time slot to use the cluster exclusively.) But setup an account in the OS for each user is too annoying. Is there a good way to grant them authority to read/write/execute their own files during a certain period of time? I am thinking something like temporary username and password that they can use to login through some interface (like a webserver) I offered. And the username and password will expire after when their reservation. Any idea?
You can share your unix user account among several users, by using SSH key authentication.
In a nutshell, each user generates a public/private key combination. The allowed public keys are then listed in the following file on the shared unix acount:
$HOME/.ssh/authorized_keys
I'm not aware of a mechanism to control when users are allowed to login. Presumably one could have a cronjob that swaps different versions of the authorized_keys file, dependent on the time of day. (Seems like over engineering the solution, users can easily over-ride this kind of restriction).
Articles:
http://wiki.centos.org/HowTos/Network/SecuringSSH
http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/pka-putty.html
So I have one part of my build that requires domain rights and does file copying.
Another part of my build runs some program that requires the user to interact with the desktop which seem to be only accomplish able by the system account.
What is the best way to work around these two items? At the moment it seems like I can only do one or the other...
One way is to do net use s: \\<share path> <password> /user:<domain user> /savecred, which will allow your system account to impersonate the domain user for the share connection.
Another way is to use the runas.exe /user:<your domain user> /savecred <program>. Note that this would require someone running runas to enter the domain user password form the context of your CC.Net user. You can do this by opening a console as the system account (there are numerous articles on this topic, because of CC.Net SVN integration) and manually running runas /savecred and providing the password.
An alternative is to create a separate COM service that runs as the domain account and have a command line tool that CC.Net invokes that call that service.
Yet another alternative would be to have the CC.Net schedule an immediate task running as the domain user. You can use schtasks.exe to do that. You'll need an xml file with the task definition, which will need to contain the domain user name and password.