rsync local root to remote server with non root preserve user:group it's possible - file-permissions

I'm writing code for create a backup rsync based.
On server a run code how root, and send with rsync some question about system, and all users accounts.
On backup server put content (via rsync) on one user account (user)
Try -azhEX --numeric-ids and -azh, y others.. but in any case I can keep the user and group id for when making a restore.
It's possible with rsync on this scenario, restore with original user:group ?
I run on both sides latest version 3.1.1 of rsync.

rsync alone cannot do this.
A very close solution to your problem is rdiff-backup which uses librsync internally and stores the user permissions and other meta-data in a separate directory.
http://www.nongnu.org/rdiff-backup/

Related

How to setup a GIT environment for developers locally while the live data is only available on a single server?

We have a scenario in which single server is running, which is getting data from the network span.
Every developer should work on their machine locally but the data to work on is only available in the server. how can I get the data to be replicated into each developers machine so that once they have completed development on their local machine, developers can push it to a GIT in the server.
PS: The network span data is constantly written to the server (data is in size of 100s of GB's).
What we have tried so far:
So we created a GIT server in the server we were getting the data on. But once a developer log in using his username then he creates a new branch in a directory. This works fine until another developer logs into the server with his username and switches to another branch in the same directory which will cause all the developers branch to the new one. which is not what we were expecting.
Probabily this question should go to https://serverfault.com/, but, anyway...
The git advantage is to have local and remotre repositories, so, in the server, you should have "only" the remote repositories, and they should be cloned in localmachines.
to work with that paradigm, or with the one you are asking for, you need a umask of 007 (depending on your distribution edit /etc/login.defs and change there)
You should have diferent groups for the diferent kind of shared projects, and a user to "own all the repositories", for example, git-adm ).
With all the prerequisites, you create with that user the base folder for all the repositories:
sudo -i
mkdir /srv/git
chown git-adm:gitgrp /srv/git
chmod g+s /srv/git
exit
The last line in the "sticky bite", wich allows to mantain the group (and avoid the problems you previously stated), so, in order to cerate a repository should be something like:
sudo su - git-adm
mkdir /srv/git/<group>/<repoName>.git
cd /srv/git/<group>/<repoName>.git
git init --bare
exit
And thats all: if the folder /srv/git/<group>/ we owned for a diferent group, then it'll keep the group.

Linux AWS EC2 Permissions with rsync

I am running a default t2.nano ec2 linux ami. Nothing is changed on it. I am trying to rsync my local changes to the server. There is a permissions issue that I don't know enough about to fix.
My structure is as follows. I'm trying to push my work to the technology directory. The technology directory is mapped to a staging domain. i.e. technology.staging.com
:/var/www/html/technology
this is from the root, and it does work fine, it's the rsync that is failing.
when I push locally to that directory I get a "failed: Permission denied (13)" error.
I'm running an nginx server and assigned permissions to the www directory as follows:
sudo chown -R nginx:nginx /var/www
My user is ec2-user which is the normal default. Here is where I am tripped up. You can see the var directory is given root access.
You can see that the www directory then has permissions set to nginx so our server can access the files. I believe I need to add the ec2-user to this directory as well as the nginx user so that I can rsync my files there and the server will still have access I'm just unsure of how to do that.
As a test, I created a test directory at this location and it worked successfully.
:/home/ec2-user/test
you can see the permission here are set for the ec2-user which is why it works i'm sure.
Here's the command I'm running on my local machine to rsync my files which fails.
rsync -azP -e "ssh -i /Users/username/devwork/company/comp.pem" company_technology/ ec2-user#1.2.3.4:/var/www/html/technology
Here's the command that was working.
rsync -azP -e "ssh -i /Users/username/devwork/company/comp.pem" company_technology/ ec2-user#1.2.3.4:/home/ec2-user/test
I have done enough research and testing to know that it's a permissions error, I just can't figure out the right way to solve it. Do I need to create a group and assign both the nginx and ec2-user to the group and then give that group the same permissions level on the :/var directory.
Side note, what permissions level do I set for the chown to make these permissions that are currently set?
I have server config files in the :/etc/nginx/conf.d/ directory that map to the directories I create inside of :/var/www/html directory so I can have multiple sites hosted on the server.
So in this example, I have a config file at :/etc/nginx/conf.d/technology.conf which maps to the directory at :/var/www/html/technology
Thank you in advance, again, I do feel like I have put forth the research and effort to show that I've gone as far as I know how to do.
The answer made sense after I spent roughly a day playing around. You have to give access to both the ec2-user and the nginx group. I believe you never want to put a user in a group that involves the server itself, I think things would go south.
After changing the owner to both the ec2-user and nginx group, it still didn't work exactly the way I wanted it to. The reason was, I needed the nginx permissions to be updated to what they had when they were assigned the user role.
Basically, theec2-user had write permissions and the server did not. we wanted the user to have write permissions so they could rsync my local files to the directory on the server, and the nginx group needed the same level of permissions to display the pages. Now that I think about it, the nginx group may have only needed read permissions to display things, but this at least solved the problem for now.
Here is the command I ran on the server to update the ownership and the permissions, as well as the output.
modify ownership
sudo chown -R ec2-user:nginx :/var/www/html/technology
modify permissions
sudo chmod -R o=rwx,g+rwx,o-w technology
The end result looks like this
You can see the permissions match, and the ownership is as we expected. The only thing I have to figure out is after I rsync new files to the server, I need to run the previous code to update the permissions again. I'm sure that will come to me later, but I hope this helps anyone in the same situation.

how to use secondary storage path for creating repositories in SVN

we have single ubuntu server. svn is installed and we are creating SVN repos and its storing in below storage path.
path1 : /dev/mapper/ubuntu--vg-root)
now we added HDD of 1TB to (/dev/mapper/vgsvnsdb-lvsvnsdb) this path.
now the challenge is how can i use this newly added storage for creating svn repos for new projects. without interrupting existing svn storage location.
path2:/dev/mapper/vgsvnsdb-lvsvnsdb
Assuming that the parent directory /dev/mapper/vgsvnsdb-lvsvnsdb exists and that you have sufficient permissions to modify that directory, the previous command creates a new repository in the directory /dev/mapper/vgsvnsdb-lvsvnsdb/repos,
You can explicitly choose the filesystem type using the --fs-type argument, which accepts as a parameter either fsfs or bdb. ( check for yours )
svnadmin create --fs-type fsfs /dev/mapper/vgsvnsdb-lvsvnsdb/repos
User the user fro which snv was installed in first place
$ chown svn:svn -R /dev/mapper/vgsvnsdb-lvsvnsdb/repos
You might want to control permissions in “/dev/mapper/vgsvnsdb-lvsvnsdb/repos”. Make sure authz-db = authz is enabled in svnserv.conf.

Joomla - File permissions & owner for a website under version control (svn)

What's the correct file owner to use locally for a joomla project, which is under svn?
When all my files are owned by apache user, I cant update my project from svn (& I cant edit these files with my normal user).
And when my files are owned by my normal user, joomla administration (Information tab) shows that some directories are read-only. Should I change only the owner of these directories (plugins, tmp...) to apache user, and let the other files owned by my user?
I have to find a compromise between the two users (apache & normal user).
Ideally you should use a different user for each site, and use the same user for svn/git.
But assuming that's not possible, keep in mind that Joomla needs to write to the folders below. Additionally, without a write access to images, you won't be able to upload images.
So the list of files/folders to assign to the apache user is:
administrator/cache
cache
logs
tmp
configuration.php
images
All the other files can be owned by the svn user; however you'll need to chmod / chown when you want to update Joomla from the backend, and install new extensions.
An easier approach is to keep only your component under svn (you can checkout only the paths you want with svn easily) and leave the rest to apache.
Finally, consider putting your svn user and Apache in the same user group, and chmod to 775.
I've done this complete differently because this is really a pain, pushing files from a Joomla installation back to a repo. Assuming you're local,
change in /etc/passwd for apache or www-data the shell from bin/sh to bin/bash.
fix the permissions of the home directory (usually /var/www ) for www-data, so that www-data can create its .svn directory. thats done by # chown -hR www-data /var/www
as root change to www-data : # sudo su www-data
go to the joomla installation/folder with the svn meta files
call svn info or whatever, so that it can store the svn credentials in .svn
you're done here, now you can call via php/system svn update in whatever folder
i've written this here www.xappcommander.com also for Joomla for exactly for this purpose which allows you to change code in an active joomla installation push back the changes to a repo without all the pain of the alternatives (sftp/ftp). Through its shell extension, you simply write #svn ci --message="whatever".
this works well also in a live stage, under plesk PHP is running with your user account, so you skip step 1-4.

db.* files in /home from Perforce?

I see several db.* files in my /home directory, and it seems they come from perforce. For example, some files are db.archmap, db.bodtext, db.change, db.changex
Are these files useful? Can I delete them? They are making my /home directory messy
You have started a server using your home directory as the Perforce server's P4ROOT folder. Those files are files that are generated from starting the server and cannot be deleted unless you want to hose your server installation. It's not clear to me how you've started the server instance, so I'll try and cover multiple bases with my answer.
If you want to start up the server under your own account, you should set the P4ROOT environment variable and point it to where you want the server to store its files. Alternatively, when you start the server, you can specify the root folder on the command line using the -r option:
p4d -r /home/mark/p4server
which would put the server's files into the directory called 'p4server' off of my home directory.
Typically it is best to run the perforce server using a user that is dedicated to running perforce. I use a user called 'perforce'. I set P4ROOT (and other variables) in that users environment. If you cannot use a separate user, it might be easier to use the -r command line option that I mentioned above.
Those files are only server files, not client files. So it is safe to delete them, but if you start the server back up it will recreate them. So you might want to uninstall the server.
Unless you are running a beta version, they have p4sandbox coming soon(maybe in the beta, I forget) which MAY create those files. I don't have a beta version, so I can't verify what new files the client may or may not create.
You can check the documentation here to see what these files do/are for.

Resources