I believe perforce super users can shelve other users' workspace files. How is this done?
I believe this would be done with p4 shelve but I'm not sure if it's possible to do it on another user's machine.
This is only possible if you have direct access to the other user's machine, in which case you can do it by logging in as a superuser, logging in as them using the p4 login USERNAME superuser command, and running the shelve command as normal. Remember to p4 logout your superuser account when you're done!
The Perforce server does not have any way to initiate a connection to a client and gain access to data that exists only in a client workspace (i.e. opened files that have not yet been shelved or submitted).
Related
Is there a mapping between a workspace and a depot in Perforce? For example if I have a workspace created on D:/myWorkspace can I run a Perforce command to find the depot from where it is created?
If you have a connection to the Perforce server this is very simple; run a command like p4 where //... or p4 client -o to see the depot(s) associated with the current client workspace.
If you're connected to the Perforce server but those connection settings don't include the name of the workspace that might be associated with the current directory, you'll need to use the p4 clients command and match the Host value to the client hostname, and then look for Root values that match the directory. Note that it's possible to have multiple matches -- people will sometimes do things like create a client with no Host value (allowing it to be used from any host) and/or a null Root value (allowing it to map any directory).
If you don't even know the address of the Perforce server and it's not set in the environment you might be out of luck; Perforce commands will automatically pick up the P4PORT setting from the system environment, the registry, P4CONFIG files, etc, but there isn't a guarantee that any given Perforce client machine will have a connection set up via one of these mechanisms (in the most perverse case, someone might specify the P4PORT on every command via the -p global flag).
When scripting Perforce commands it is generally reasonable to assume a correctly configured environment that includes valid P4PORT/P4USER/P4CLIENT settings, and error out if the user hasn't provided those. A script run from within a shell where the user is using the P4 CLI will already have a correctly configured environment, as will a script run from P4V as a "Custom Tool".
I just uploaded my local svn file repository to an svn host. I notice that when checking out the code to my local (Linux) computer I have to provide my username and password (as expected) but subsequent operations (checkout, commit, log, etc.) does not require any authentication, so I take it that after initial login I stay logged in for some time.
My questions related to this are:
How long do I stay logged in like this?
What would trigger my access to the repository to expire?
Can I manage the expiration time, and if so, is it done server side, or in my local subversion configuration?
I'm running svn 1.7.9 on Ubuntu 13.10 Linux.
Thanks!
1) How long do I stay logged in like this?
You are not logged in. Your authentication tokens are saved somewhere under ~/.subversion/auth.
2) What would trigger my access to the repository to expire?
If you remove the file under ~/.subversion/auth which stores your password for the particular repository, then you will have to reenter the password again.
3) Can I manage the expiration time, and if so, is it done server side, or in my local subversion configuration?
That really depends on how authentication is configured on the server side.
Btw, you can prevent Subversion from saving your authentication tokens if you checkout using --no-auth-cache.
UPDATE
There is a lot more to this, as #BenReser points out:
Realize that the password is not necessarily stored under ~/.subversion/auth. We support a variety of platform specific credential storage (Windows Crypto API, OS X Keychain) and even in 1.8 GPG Agent. The GPG Agent case would behave somewhat like what he's envisioning, where the password is cached only for a certain amount of time, which he could configure. There is also NTLM/Kerberos support that may behave like a single sign on as well. So frankly it's really hard to answer this question without more details about his configuration.
I need to copy a depot from one Perforce server to another. The file revision history needs to be intact but the user information and workspace information can not be copied to the new server.
I've tried a standard checkpoint creation and restore procedure, but if there exist users or workspaces with the same name on both servers, the source server will overwrite this info on the destination server. This is pretty bad if those user accounts and workspaces do not have exactly identical details.
The goal of this sort of operation is to allow two separate, disconnected groups to view a versioned source tree with revision history. Updates would be single directional with one group developing and one just viewing. Each group's network is completely enclosed, no outside connections of any kind.
Any ideas would be appreciated, i've been busting my brains on this one for a while.
EDIT:
Ultimately my solution was to install an intermediate Perforce server on the same machine as my source server. Using that I could do a standard backup/restore from the source server to the intermediate server and then delete all unwanted meta data in the intermediate server before backing up from the intermediate server to the final destination server. Pretty complicated but it got the job done and it can all be done programatically in Windows Power Shell.
There are a few ways, but I think you are going about this one the hard way.
Continue to do what you are doing, but delete the db.user, db.view(I think) and db.group. Then when you start the perforce server, it will create these, but they will be empty, which will make it hard for anyone to log in. So you'll have to create users/groups. I'm not sure if you can take those db files from another server and copy them in, never tried that.
The MUCH easier way, make a replica. http://www.perforce.com/perforce/r10.2/manuals/p4sag/10_replication.html Make sure you look at the p4d -M flag to make sure it's a read only replica. I assume you have a USB drive or something to move between networks, so you can just issue a p4 pull onto the USB drive, then move the drive, and either run it off the USB, or issue another p4 pull, pulling to a final server. Never tried this, but with some work it should be possible, you'll have to run a server off the USB to issue the final p4 pull.
You could take a look at perforce git fusion, and make some git clones.
You could also look at remote depots. Basically you create a new depot on your destination server, and point it at a depot on your source server. This works if you have a fast connection between the 2 servers. Protections are handled by the destination server, as to who has access to that new depot. The source server can be set up to share it out as read only to the destination server. Here is some info
http://answers.perforce.com/articles/KB_Article/Creating-A-Remote-Depot
Just make sure you test it during a slow period, as it can slow down the destination server. I tried it from 2 remote locations, both on the east coast US, and it was acceptable, but not too useful. If both servers are in the same building it would be fine.
Every time I commit a file in svn I get the following message:
ATTENTION! Your password for authentication realm:
http://domainname.com:80 “domainname.com”
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/root/.subversion/servers'.
Store password unencrypted (yes/no)? no
I don't want this authentication; how can I get rid of this warning?
You are not storing the password in Subversion because you answered no to the question whether or not you want to store this password.
I take it you want to eliminate this error warning message entirely. There are two ways to handle that:
The easy, but hard way: You can specify svn --no-auth-cache each and every time you a Subversion command. It's easy to do since it requires no real action on your part. It's hard because you have to do this almost every time you use a Subversion command (especially one that touches the repository like checkout and commit).
The hard, but easy way: You can modify your user's Subversion configuration not to ask if you want to store this information. (BTW, why are you running as root? You like living life on the edge? Better off running as a user and configure sudo to allow you to do the root stuff you need. That way, you can track who's doing what, and you don't do something that could accidentally bring the server down. In fact, many Unix/Linux systems by default no longer allow a user to sign in as root. You have to do sudo). This is hard because you have to do something, but easy because once you do it, you don't have to do anything again.
You have the name of the file that you need to edit (/root/.subversion/servers). Look for the [global] section and look for the line # store-passwords = no and remove the # from the beginning of the line. You can also do the same for the # store-plaintext-passwords = no line and the # store-auth-cred = no line. While, you're at it, you can also delete the files under the auth directory which is where Subversion stores its credentials. This will completely eliminate already stored passwords. More information can be found in the on line Red Bean Subversion manual.
Now, when you do a Subversion command that touches the repository, it'll ask you for a user name and password and won't ask if you want to store them.
You copied the full warning message here. Reading it instead of just copy/pasting it would answer your question:
you can avoid future appearances of
this warning by setting the value of
the 'store-plaintext-passwords' option
to either 'yes' or 'no' in
'/root/.subversion/servers'.
The subversion client is only asking for authentication because the server requires it. To get rid of the authentication requirement, you'll have to change the server's configuration (e.g., in Apache, get rid of AuthType, AuthName, and AuthUserFile). You can use other authentication methods which do not require passwords (for example, client certificates).
If you just want to get rid of the save password unencrypted prompt, you can set store-plaintext-passwords=off (by editing ~/.subversion/config) or you can make encrypted passwords work by getting (on Unices) the GNOME keyring or KDE wallet running. On Windows, SVN should automatically use built-in NTFS encryption; on Mac OS X, the Keyring. See the Client Credentials section of the SVN Manual for further details.
You could also encrypt your home directory on Unix. Then the credentials would be encrypted as well (but of course available to any program running as you or root while you're logged in, similar to the NTFS encryption).
If you don't want SVN to store passwords at all, encrypted or not, set store-passwords=no in the SVN config file.
I use rsync to mirror a remote server. It is said that using a root password with rsync is dangerous, so I created a special rsync user. It seems to work fine, but cannot copy some files because of file permissions. I want to mirror whole directories for backup, and I guess this cannot be done without using root password, I mean if root does not give permissions on a specific files, no other account can read them. Is there other solutions and why shouldn't I use root account in rsync (I only do one way copying, that does not effect source).
If you want the whole server, then yes, you need root. However, instead of "pulling" (where you have a cron on your local server that does "rsync remote local"), can you possibly do it by "push" (where you have a cron on the remote server that does "rsync local remote"?) In this case, you won't need to configure the remote server to accept inbound root connections.
One option is to use an ssh login as root, but using ssh pubkey authentication instead of a password. In general, pubkeys are the wya to go, if you want to automate this later.
You'll want to look into the PermitRootLogin sshd_config setting, in particular the without-password setting or, if you want to get even more sophisticated and (probably) secure, the forced-commands-only setting.
Some useful links:
http://troy.jdmz.net/rsync/index.html
http://www.debian-administration.org/articles/209