So as of two days ago, i had myself a shiny new SVN server. I set it up for WebDAV with no problems. It wasn't until i tried to host multiple projects that i ran into trouble.
At first, i had all of the project folders in one repository. But then i saw the error in my ways, and switched to multiple repositories. Rather than edit the /etc/apache2/sites-available/default file with every new project, i elected to use the svnserve deamon.
So, the problem is, i cn only make commits from Eclipse when the daemon is run as root. If not, I get a Permission Denied Error. Any ideas? Here are the directory stats:
drwxr-xr-x 6 root root 4096 2011-06-07 09:38 .
drwxr-xr-x 4 root root 4096 2011-06-05 00:48 ..
lrwxrwxrwx 1 svn svn 6 2011-06-06 22:35 all -> repos/
drw-rw-r-- 6 svn svn 4096 2011-06-06 13:53 EmpowerView
drw-rw-r-- 6 svn svn 4096 2011-06-06 13:54 GoogleVoicemail
-rw-rw-r-- 2 svn svn 307 2011-06-07 08:47 passwd
drw-rw-r-- 6 svn svn 4096 2011-06-06 13:54 PerlinNoise
drw-rw-r-- 7 svn svn 4096 2011-06-05 02:15 repos
-rw-rw-r-- 3 svn svn 2278 2011-06-07 08:46 svnserve.conf
EDIT
I tried the suggested re-checkout with the daemon not running as root, and still no cigar. Same permission error.
EDIT 2
I also tried running the daemon as the user svn, but no such luck. At one point I screwed up my primary group and no longer had sudo privileges! I had to hack into my own server through a buddy's account
EDIT 3 ANSWER
Well, after a few hours of tinkering, here is the setup that i got to work.
First I deleted any existing checkouts, and killed the deamon.
Then I set all the permissions to 774 for all my repositories (see below)
Next, I ran the daemon with this command sudo -u svn -- svnserve -d -r /storage/svn/
This allowed me to run the deamon as the user 'svn' without entering a password. (svn has no password or shell for security reasons)
Finally, I double checked all my config files, and was able to do checkouts exactly as hoped.
Repositories Directory
drwxr-xr-x 6 root root 4096 2011-06-07 10:34 .
drwxr-xr-x 4 root root 4096 2011-06-05 00:48 ..
lrwxrwxrwx 1 svn svn 6 2011-06-06 22:35 all -> repos/
drwxrwxr-- 6 svn svn 4096 2011-06-06 13:53 EmpowerView
drwxrwxr-- 6 svn svn 4096 2011-06-06 13:54 GoogleVoicemail
-rwxrwxr-- 2 svn svn 307 2011-06-07 08:47 passwd
drwxrwxr-- 6 svn svn 4096 2011-06-06 13:54 PerlinNoise
drwxrwxr-- 7 svn svn 4096 2011-06-05 02:15 repos
-rwxrwxr-- 3 svn svn 2273 2011-06-07 09:50 svnserve.conf
(Note: All of my repositories share common editors and permissions, so in each repositories conf/ folder, i put hardlinks to the passwd and svnserve.conf files above)
Probably the svn daemon has read permission to your repository but not write permission.
First find out under what user the svn daemon runs. Then chown the full repository to that user. That way the daemon can write your commits also.
Weird things happen when you commit, or checkout as root. Try to checkout a given repository not as root, and if that works you should be able to commit to it as a regular user thereafter.
If that still doesn't work, check the permissions on the repository itself. It's possible that the permissions aren't set in order to allow non-root users commit access.
Related
I have a question about the right approach for /var/www/somesite folder permissions.
The story is like this.
I have 5 developers, I put them all as members of devteam group
I have the website folder /var/www/mywebsite and I know that /var/www/mywebsite/info folder rquires apache to write into it. I'm using ACLs because I believe that's the best approach to control what I'm looking for.
So... I configured the whole thing like this:
The structure:
joel#server:$ ls -la /var | grep www
drwxrwxr--+ 3 www-data www-data 4096 Jul 11 01:12 www
joel#server:$
joel#server:$ ls -la /var/www
drwxrwxr--+ 3 www-data www-data 4096 Jul 11 01:12 .
drwxr-xr-x 15 root root 4096 Jul 11 14:37 ..
dr-xrwsr--+ 16 www-data www-data 4096 Jul 12 06:49 mywebsite
joel#server:$
You can see that setgid is set on mywebsite so that it'll make all executables to run with the privileges of the group
for /var/www
joel#server:~$ sudo getfacl -p /var/www
# file: /var/www
# owner: www-data
# group: www-data
user::rwx
user:www-data:r-x
group::r-x
group:www-data:rwx
group:devteam:rwx
mask::rwx
other::r--
for /var/www/mywebsite
joel#server:~$ sudo getfacl -p /var/www/mywebsite
# file: /var/www/mywebsite
# owner: www-data
# group: www-data
# flags: -s-
user::r-x
user:www-data:r-x
group::r-x
group:www-data:rwx
group:devteam:rwx
mask::rwx
other::r--
for /var/www/mywebsite/info
joel#server:~$ sudo getfacl -p /var/www/mywebsite/info
# file: /var/www/mywebsite/info
# owner: joel
# group: www-data
# flags: -s-
user::rwx
user:www-data:rwx
group::r-x
group:www-data:rwx
mask::rwx
other::r--
Now... everything seems to work, except that when one of the developers tries to use git on that folder, they get this error:
fatal: not a git repository (or any of the parent directories): .git
Since I did run git init --shared=group and I know for sure that the directory structure does have .git in it (see structure below), so... I was sure it's permissions.
Once I've added the users to be part of www-data group, they were able to run all the git commands they wanted. (it makes sense, since the files in the directory are with owner: joel group: www-data).
The structure looks like that:
joel#server:~$ ls -la /var/www/mywebsite/
total 107928
dr-xrwsr--+ 16 www-data www-data 4096 Jul 12 06:49 .
drwxrwxr--+ 3 www-data www-data 4096 Jul 11 01:12 ..
-rwxrwxr--+ 1 joel www-data 213 Jul 11 01:25 .editorconfig
-rw-rw-r--+ 1 joel www-data 2013 Jul 11 20:48 .env
drwxrwxr-x+ 8 joel www-data 4096 Jul 12 10:55 .git
-rwxrwxr--+ 1 joel www-data 111 Jul 11 01:25 .gitattributes
-rwxrwxr--+ 1 joel www-data 309 Jul 11 01:25 .gitignore
-rwxrwxr--+ 1 joel www-data 412 Jul 11 21:00 .htaccess
-rwxrwxr--+ 1 joel www-data 174 Jul 11 01:25 .styleci.yml
drwxrwsr--+ 12 joel www-data 4096 Jul 11 01:25 helper
-rwxrwxr--+ 1 joel www-data 1686 Jul 11 01:25 mainly
-rw-rw-r--+ 1 joel www-data 1304 Jul 11 01:25 pipelines.yml
drwxrwsr--+ 3 joel www-data 4096 Jul 11 01:25 info
-rwxrwxr--+ 1 joel www-data 707 Jul 11 01:25 story.php
-rwxrwxr--+ 1 joel www-data 2069 Jul 11 09:50 offset.json
The reason it's me as the owner of everything, is because I was the one who pulled it from the repository to begin with, but, it'll probably change since these developers will pull the stuff they need while logging in with their credentials, and, it'll change.
On to my questions:
Is this the right approach to the order and structure of the website?
I don't want my developers to be part of www-data group because, well, because that group is not for them! it's for apache to run the server. What can I do? How can I set it up currectly so that they'll be able to work git without being part of the www-data group? (I thought about chaning the ownership of the whole website to be owned by the devteam group, but, what will happened with apache2 service then?)
How come my /var/www/mywebsite/info doesn't have devteam permissions in it's ACL (do I really need to set it up for all subfolder if it's already setup for the parent?)
Why do I have mask::rwx as part oof my ACL configuration? I don't rememebr I set it up.
Am I doing the right thing with setting the setgid in that way that all my folders are will have the group privileges for executables?
I really appriciate your help on this subject.
The right approach (TM) is to not give anybody access to your server, but have them go through version control and a controlled deployment process - this way you'll have a chance to restore the server after some failure situation, an audit trail of what software was installed when etc.
As a minimum, either you or a script might pull a tagged version from a central git repo every now and then. This way it's only you or the script to ever write to Apache's directory. All developers collaborate through git, in a central repository. They send pull requests, and you'll have a trail of who did what when and why.
On the central repository, somebody merges pull requests, tags - and you're set.
Of course - you can go more fancy, but the situation that you describe sounds like a bad workaround for a problem that nobody should have (live write access to a server, for a dev team of >1 size)
Edit: this even holds on a development machine. If hate to make a change and debug why it doesn't work, only to find out that it's due to somebody else's change, after an hour of useless debugging
In my open vpn server, i am ensuring cron file permission to be only accessable from root user.
I have removed the at.deny and cron.deny files and have created at.allow and cron.allow and 0600 permissions are applied for files, both files are empty and file permissions are as below, which clearly says root has read and write access.
-rw------- 1 root root 0 Jul 21 08:40 cron.allow
-rw------- 1 root root 0 Jul 21 08:40 at.allow
however this change allows my openvpnas user to still list the crontab and even allows to edit cron.
openvpnas#openvpnas2:~$ crontab -l
no crontab for openvpnas
Where as when the file permissions are as below,
-rw-r--r-- 1 root root 0 Jul 21 08:41 cron.allow
-rw-r--r-- 1 root root 0 Jul 21 08:41 at.allow
It restricts my non root users to access or edit cron files! This issue is only with one of my server, where as other server permissions and behaviours are as expected,
openvpnas#openvpnas2:~$ crontab -l
You (openvpnas) are not allowed to use this program (crontab)
See crontab(1) for more information
Please provide your inputs on this, this has kept me blocked from continuing my work.
This issue i faced was in Ubuntu 18.04 instance,
Current /usr/bin/crontab permission was as below,
-rwxr-sr-x 1 root crontab 39352 Nov 16 2017 /usr/bin/crontab
Had to change the group user from crontab to root and file permission to as below,
sudo chmod 4755 /usr/bin/crontab
sudo chown root:root /usr/bin/crontab
-rwsr-xr-x 1 root root 39352 Nov 16 2017 /usr/bin/crontab
This permission restricts the non-root user to schedule cronjobs. The access can be allowed to non-root users by adding the user names in cron.allow file.
openvpnas#openvpnas2:~$ crontab -l
You (openvpnas) are not allowed to use this program (crontab)
See crontab(1) for more information
First, the setup. I'm running a haneWin nfs server on a Windows Server 2012, mounting it at startup in a ubuntu server with this fstab entry ~ip~:/sharenfs /srv/share nfs rw 0 0
The umask is set on the windows server to 000, which indeed results in every user on ubuntu having rw access to the entire share.
Now here's the problem: I want to use the nfs share to store all our git repos so that the windows server can back them up together with all its data. In an earlier setup the ubuntu host provided a nfs share which worked perfect, but for storage reasons the windows server should host the share.
The git repos are supposed to be created automatically by redmine, which worked fine prior to the nfs change, but now it just fails silently. The logs dont provide any useful information.
But here's something that does provide information, if I create a new directory on the nfs share, run git init, the following comes out:
error: could not lock config file /srv/share/git/metatest/test1/.git/config: File exists
... (this line shows a total of 6 times)
error: could not lock config file /srv/share/git/metatest/test1/.git/config: File exists
Reinitialized existing shared Git repository in /srv/share/git/metatest/test1/.git/
The dir was completely empty! In fact running rm -rf .git; git init has the same output.
A ls -lAhR shows this
./.git:
total 22K
drwxrwxrwx 2 git git 4.0K Jun 5 17:07 branches/
-rw-rw-rw- 1 git git 53 Jun 5 17:07 config
-rw-rw-rw- 1 git git 21 Jun 5 17:07 config.lock
-rw-rw-rw- 1 git git 73 Jun 5 17:07 description
-rw-rw-rw- 1 git git 23 Jun 5 17:07 HEAD
drwxrwxrwx 2 git git 4.0K Jun 5 17:07 hooks/
drwxrwxrwx 2 git git 4.0K Jun 5 17:07 info/
drwxrwxrwx 4 git git 4.0K Jun 5 17:07 objects/
drwxrwxrwx 4 git git 4.0K Jun 5 17:07 refs/
./.git/branches:
total 0
./.git/hooks:
total 17K
-rwxrwxrwx 1 git git 452 Jun 5 17:07 applypatch-msg.sample*
-rwxrwxrwx 1 git git 896 Jun 5 17:07 commit-msg.sample*
-rwxrwxrwx 1 git git 189 Jun 5 17:07 post-update.sample*
-rwxrwxrwx 1 git git 398 Jun 5 17:07 pre-applypatch.sample*
-rwxrwxrwx 1 git git 1.7K Jun 5 17:07 pre-commit.sample*
-rwxrwxrwx 1 git git 1.3K Jun 5 17:07 prepare-commit-msg.sample*
-rwxrwxrwx 1 git git 1.4K Jun 5 17:07 pre-push.sample*
-rwxrwxrwx 1 git git 4.8K Jun 5 17:07 pre-rebase.sample*
-rwxrwxrwx 1 git git 3.6K Jun 5 17:07 update.sample*
./.git/info:
total 512
-rw-rw-rw- 1 git git 240 Jun 5 17:07 exclude
./.git/objects:
total 8.0K
drwxrwxrwx 2 git git 4.0K Jun 5 17:07 info/
drwxrwxrwx 2 git git 4.0K Jun 5 17:07 pack/
./.git/objects/info:
total 0
./.git/objects/pack:
total 0
./.git/refs:
total 8.0K
drwxrwxrwx 2 git git 4.0K Jun 5 17:07 heads/
drwxrwxrwx 2 git git 4.0K Jun 5 17:07 tags/
./.git/refs/heads:
total 0
./.git/refs/tags:
total 0
Interestingly though when redmine tries to create a repository the directory isnt even created. Again, it fails silently, no useful output.
When I try to run git add or from a remote pc push any changes from existing repos that where created when redmine did work, I get
fatal: error when closing sha1 file: Permission denied
This all makes absolutely no sense to me. Any ideas?
The question might not be entirely right about the cause of the problem. It turned out, that the gitolite installation had been broken by porting it over to a SMB mount, and then after moving it to an NFS mount the problem persisted.
I can't tell for sure if that's what happened, but right now it's working on an NFS share and this is my most probable explanation.
Another explanation would be that hanewin nfs was the problem, since right now running the Windows Server 2012 NFS Server it's working.
I have added the following to the file /etc/sudoers using the visudo command:
nick ALL=(ALL:ALL) ALL
But when I log in as nick and attempt something like mkdir .ssh I get:
mkdir: cannot create directory ‘.ssh’: Permission denied
Likewise, I cannot save files I have edited.
Running ls -la from the home directory gives me:
drwxr-xr-x 5 nick nick 4096 Apr 7 19:07 .
drwxr-xr-x 3 root root 4096 Apr 7 17:32 ..
-rw-r--r-- 1 nick nick 220 Aug 31 2015 .bash_logout
-rw-r--r-- 1 nick nick 3771 Aug 31 2015 .bashrc
drwx------ 2 nick nick 4096 Apr 7 18:29 .cache
drwxr-xr-x 2 root root 4096 Apr 7 19:07 .nano
-rw-r--r-- 1 nick nick 675 Aug 31 2015 .profile
Which if I'm not mistaken is showing that I have no write access to anything. (Correct me if I'm wrong. I'm only passingly familiar with UNIX permissions.)
Why can't this user do anything despite being given full permissions in sudoers?
UPDATE:
This problem fixed itself. I do not know what the problem was but it was no longer a problem when I logged on a couple days later.
For the record, I was attempting to configure a fresh DigitalOcean server running Ubuntu 15.10 x64. My local computer is a MacBook running El Capitan.
My guess is that the remote server restarted or somehow otherwise incorporated the change automatically in the interim. I had already tried running sudo reboot producing no results, so I'm still not sure how this could be.
I was also experiencing some local WiFi connection dropping at the time but as my SSH connection seemed to be operational I'm not sure if this could be related.
I'm also not an expert to Linux, but to me it seems like you have to use sudo mkdir .ssh instead of mkdir .ssh. You allowed your user to behave like root(who has rights to write to directory), but for doing that you have to use sudo command.
Here is the simple explanation of how it works(with pictures): https://www.garron.me/en/linux/visudo-command-sudoers-file-sudo-default-editor.html
Here is the serious documentation: https://help.ubuntu.com/community/Sudoers
I am configuring hadoop on Ubuntu os. I need to create RSA key pair to allow hadoop to interact with its nodes, so i running this command:
hadoop#ubuntu:~$ ssh-keygen -t rsa -P ""
then I get this:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hadoop/.ssh/id_rsa):
Could not create directory '/home/hadoop/.ssh': permission denied.
Enter passphrase (empty for no passphrase ):
Enter same passphrase again:
open /home/hadoop/.ssh/id_rsa failed: No such file or directory.
Saving the key failed: /home/hadoop/.ssh/id_rsa.
Forgot to create .ssh dir in your home?
Try that:
mkdir -p ~/.ssh
then re-run ssh-keygen.
Also possibly you doing ssh-keys creation from wrong user.. You started that shell using sudo?
Try to set HOME dir manually or enter right path in prompt.
check your home directory name and permissions
echo $HOME
cd ~ ; ls -l
ls -l .ssh
ls -lR .ssh
if above output is OK and you have correct permissions, perhaps your quota is full
try with "sudo" and see what happens...
Seems like current user doesn't own the contents under home directory.
Gain the ownership as shown as below:
admin#mydb22-02:~$ sudo chown admin.admin /home/admin/
admin#mydb22-02:~$ ls -la
total 32
drwxr-xr-x 2 admin admin 4096 Nov 3 23:29 .
drwxr-xr-x 3 admin admin 4096 Dec 23 2012 ..
-rw------- 1 admin admin 191 Feb 13 2013 .bash_history
-rw-r--r-- 1 admin admin 220 Apr 3 2012 .bash_logout
-rw-r--r-- 1 admin admin 3486 Apr 3 2012 .bashrc
-rw-r--r-- 1 admin admin 675 Apr 3 2012 .profile
-rw-r--r-- 1 admin admin 0 Nov 3 23:29 .sudo_as_admin_successful
-rw------- 1 admin admin 4221 Nov 3 20:31 .viminfo
generating keys would work now as .ssh directory will now be created and owned by current user after generating the assymetric keys
I have spent arround 1 hr on this and finally got the solution. It is due to permission problem. You have to use chown for your 'hadoop user'.
1. First make hadoop directory.
cd /home
mkdir hadoop
then check 'ls -l'. it gives result like :
drwxr-xr-x 2 hadoop hadoop 4096 Aug 22 22:17 hadoop
2. sudo chown hadoop.hadoop /home/hadoop/
3. Then run remaining command for key generater.