A client of mine is heavily using Samba (workgroup) from their Windows PC. I used to add samba shares or symbolic links within existing shares so they could access the data folder of different webservices hosted on the server. So far so good.
Recently, they purchased a secondary server to off-load part of the existing services, but they would like to keep the convenient file access through Samba.
Now: I hate samba. Configuration sucks. But the user rules. I could have added a secondary samba server (or client) on the secondary PC, then asked them to log on the proper share. But here is a very Unix way to do it:
On the new server (aka "remote"):
''
# Create a dedicated user for uploading to www-data:
useradd -g 33 www-remote
# Set his umask in /etc/passwd for non-interactive accesses:
chfn -o "umask=0002" www-remote
# Create its home and SSH directory
mkdir -p /home/www-remote/.ssh
# Set the interactive umask for interactive shell (if any):
echo 'umask 002' >> /home/www-remote/.bash_profile
''
Then get the local ''/root/.ssh/id_rsa.pub'' key and paste it to his authorizations:
''
cat >> /home/www-remote/.ssh/authorized_keys
# set the expected rights
chown -R www-remote:www-data /home/www-remote
chmod -R go-rwx /home/www-remote/.ssh
''
Finally we will allow only file transfer protocols for this user:
''
apt-get install sshfs
usermod -s /usr/bin/rssh www-remote
echo 'user=www-remote:001:100110:' >> /etc/rssh.conf
Then back on localhost:
''
# make www-data group-writeable (understand what it means!)
sudo chfn -o "umask=0002" www-data
''
Recently, they purchased a secondary server to off-load part of the existing services, but they would like to keep the convenient file access through Samba.
Now: I hate samba. Configuration sucks. But the user rules. I could have added a secondary samba server (or client) on the secondary PC, then asked them to log on the proper share. But here is a very Unix way to do it:
On the new server (aka "remote"):
''
# Create a dedicated user for uploading to www-data:
useradd -g 33 www-remote
# Set his umask in /etc/passwd for non-interactive accesses:
chfn -o "umask=0002" www-remote
# Create its home and SSH directory
mkdir -p /home/www-remote/.ssh
# Set the interactive umask for interactive shell (if any):
echo 'umask 002' >> /home/www-remote/.bash_profile
''
Then get the local ''/root/.ssh/id_rsa.pub'' key and paste it to his authorizations:
''
cat >> /home/www-remote/.ssh/authorized_keys
# set the expected rights
chown -R www-remote:www-data /home/www-remote
chmod -R go-rwx /home/www-remote/.ssh
''
Finally we will allow only file transfer protocols for this user:
''
apt-get install sshfs
usermod -s /usr/bin/rssh www-remote
echo 'user=www-remote:001:100110:' >> /etc/rssh.conf
''
The 6 bits are to allow in this order: rsync, rdist, cvs, sftp, scp and svnserve (so 100110 is rsync+sftp+scp). Note that ''scp'' is the protocol used by ''sshfs'' further below.
Then back on localhost:
''
# make www-data group-writeable (understand what it means!)
sudo chfn -o "umask=0002" www-data
''
You should now be able to tranfer files like this:
''
rsync --progress -a --exclude .git --exclude *.sqlite * www-remote@myserver.com:/var/www/td.myserver.com
''
''
# and Mount the remote:
sshfs -p 12345 -o allow_other,uid=33,gid=33,umask=0002 www-remote@192.168.1.111:/var/www/remoteproject/data /var/smb/localproject/data
''
Then go and look at it from the remote side in ''/var/www/remoteproject/data'': it should be owned by ''www-remote:www-data'' and group-writable by www-data.
Note: to unmount the remote:
''
fusermount -u /var/www/localproject/data
''
Finally, to have the remote mounted you can add it to ''/etc/fstab'' this way:
''
echo 'www-remote@192.168.1.111:/var/www/remoteproject/data /var/smb/localproject/data fuse.sshfs port=12345,allow_other,uid=33,gid=33,umask=0002,reconnect 0 0
''
And test it, e.g. with ''echo "t"> /var/smb/localproject/data/t''
Note, if the local it itself a web zone (e.g. ''/var/www/localproject/data'' instead of ''/var/smb/localproject/data''), then you can test it as if you were ''www-data'' with:
''
su -s /bin/bash www-data # we must provide a shell for this nologin account
touch /var/smb/localproject/data/remotetest
''
There is certainly a way to test it directly logged as a samba user from withing the local server, but as I said, the less I know about samba, the more I know about linux (such as SSH tunneling).
# and Mount the remote:
sshfs -p 12345 -o allow_other,uid=33,gid=33,umask=0002 www-remote@192.168.1.111:/var/www/remoteproject/data /var/smb/localproject/data
''
Then go and look at it from the remote side in ''/var/www/remoteproject/data'': it should be owned by ''www-remote:www-data'' and group-writable by www-data.
''
fusermount -u /var/www/localproject/data
''
Finally, to have the remote mounted you can add it to ''/etc/fstab'' this way:
''
echo 'www-remote@192.168.1.111:/var/www/remoteproject/data /var/smb/localproject/data fuse.sshfs port=12345,allow_other,uid=33,gid=33,umask=0002,reconnect 0 0
''
And test it, e.g. with ''echo "t"> /var/smb/localproject/data/t''
Note, if the local it itself a web zone (e.g. ''/var/www/localproject/data'' instead of ''/var/smb/localproject/data''), then you can test it as if you were ''www-data'' with:
''
su -s /bin/bash www-data # we must provide a shell for this nologin account
touch /var/smb/localproject/data/remotetest
''
There is certainly a way to test it directly logged as a samba user from withing the local server, but as I said, the less I know about samba, the more I know about linux (such as SSH tunneling).
No comments:
Post a Comment