all my servers are offline just now.

Submitted by ashleydrees on Tue, 02/10/2015 - 06:05 Pro Licensee

I install cloudmin yesterday, and today i find that all the sties are offline, i am not sure if they are linked or that the update i plied yesterday with a reboot has caused this. Error is ALL sites are offline - this is a typical error message .

access to /_images/logo_old.gif denied (filesystem path '/home/rqysi riz/public_html') because search permissions are missing on a component of the path

i understand the error but somehow all of them are offline - it is though the permissions are messed up for apache... i might add i set up LDAP here and it has been working fine till now.. if it is that.. i will add www-data to rqysiriz group and see if that allows access.

Status: 
Closed (fixed)

Comments

Submitted by ashleydrees on Thu, 02/12/2015 - 03:23 Pro Licensee

just checking the LDAP groups www-data IS already in the group for rqysiriz (the site i was checking on)

Submitted by ashleydrees on Thu, 02/12/2015 - 02:52 Pro Licensee

OK, i have a work around.. when i added o+x to the /home/admin and /home/admin/public_html i could bring them back online - it is now.

drwxr-x--x 10 cjadministrator   cjadministrator   4096 Sep  1 10:19 cjadministrator/
drwxr-x--x 12 hajomsrr          hajomsrr          4096 Aug 11  2014 hajomsrr/
drwxr-x--x 10 lndtosuj          lndtosuj          4096 Aug 13 22:51 lndtosuj/
drwxr-x--x 13 reqehavw          reqehavw          4096 Aug 11  2014 reqehavw/
drwxr-x--x 15 rqysiriz          rqysiriz          4096 Sep  4 16:27 rqysiriz/
drwxr-x--x 10 ubzuuudk          ubzuuudk          4096 Jul 28  2014 ubzuuudk/
drwxr-x--x 10 vawmewd7          vawmewd7          4096 Jul 21  2014 vawmewd7/
drwxr-x--x  3 virtualminsupport virtualminsupport 4096 Jul 18  2014 virtualminsupport/
drwxr-x--x 11 yecDoll1          admin             4096 Aug 19 05:22 yecDoll1/

Submitted by andreychek on Tue, 02/10/2015 - 09:42

Howdy -- on a typical setup, you shouldn't need to set that particular permission. The permissions on those dirs are usually "750".

It does mean that a user on your server could potentially access files that are world readable within another user's homedir.

Though, in many cases, that risk may be preferable to the alternative of the site not working, but hopefully we can determine what the issue is here.

So it sounds like you're saying you are using LDAP there?

Normally adding www-data to the Virtual Server owner's group is all it takes to resolve that.

Submitted by ashleydrees on Thu, 02/12/2015 - 02:53 Pro Licensee

I already have www-data in all of the groups... it was working until last night, and the two things i did last night was update the kernel and reboot and install the CloudMin.

OK, i thought it should have been 750, i will change one of the unimportant sites back to play around with things, I have made NO changes to the system other than update as required.

Submitted by ashleydrees on Thu, 02/12/2015 - 02:59 Pro Licensee

OK, just had a look in groups, my admin users all have www-data in their groups.. so groups www-data should show all the groups that it is in.

"groups www-data"

it returns

"www-data : www-data list"

BUT www-data is in ALL the administrators ldap groups... i guess it is not actually looking in ldap..

# /etc/nsswitch.conf
.....
# passwd:         compat
# pre_auth-client-config # passwd: files ldap
passwd: files ldap
# group:          compat
# pre_auth-client-config # group: files [UNAVAIL=continue NOTFOUND=continue TRYAGAIN=continue] ldap
group: files ldap
....

Submitted by ashleydrees on Wed, 02/11/2015 - 16:24 Pro Licensee

OK, i changed one of the unused domains back to 750 for the admin home and the public_html and the site is again broken - www-data IS in the group for that domain so the issue seems to be that somehow the system is no longer looking up group membership in LDAP since last night.

Submitted by andreychek on Tue, 02/10/2015 - 20:21

I'm not sure of a reason why the Cloudmin installation might cause that. I don't believe it touches any config files relating to Apache or even groups. It should be completely safe to install on a server running Virtualmin.

So that does leave the question -- what in the world did cause that?

LDAP does make things a bit more complicated, and that's not quite my area of expertise, but it might be good to try and rule out that as a culprit.

Are your Virtual Server owner users stored in LDAP? Or are they in /etc/passwd? Same with the groups -- is www-data in /etc/group or in LDAP?

The other thing I'm wondering -- if you just updated your kernel, that suggests that your server was rebooted. So perhaps a change was made recently that maybe wasn't active on your server until the system was restarted.

Can you think of anything else in the few days prior to updating the kernel that may have changed?

Submitted by ashleydrees on Thu, 02/12/2015 - 03:26 Pro Licensee

All groups and users are in LDAP, and it has been working fine since install (mid 2014) .

The system has been kept up to date as security updates required and rebooted when necessary - as i said, i am unsure quite what it was that broke this - but from nsswitch you can see it should be getting the groups from "files ldap". the strange thing is that if I "id domainowner" i get the expected result (LDAP is consulted)- however if i use "groups www-data" i get the restricted list, i know that the system is using the LDAP for virtuamin domain owners as it does find them and returns the expected info - however - how could the groups NOT show the full list of groups that www-data is in - which is exactly why the sites became broken.

i changed the order in the nsswitch file to put ldap first - but the same return, something has effected the function of LDAP and groups as the system no longer gets the LDAP groups as well as the files groups, but it is not across the board as the groups command works for "normal" users.

I will review what was installed in the last week. i will also work through the steps i used to activate LDAP too, to make sure that nothing has changed, but from what i can see in both the files and webmin ldap modules - everything seems in order.

Submitted by ashleydrees on Wed, 02/11/2015 - 16:16 Pro Licensee

OK, so the system looks up the group www-data - and finds a group in /etc/groups and then does not look any further.. no matter what i have changed in nsswitch it seems to fail to pick up the group membership if the group is defined in /etc/groups and membership is in the ldap.

Submitted by ashleydrees on Wed, 02/11/2015 - 16:15 Pro Licensee

Any help or thoughts welcome - i have to leave this now and go to a client site - i hope the attention to OSX and Retrospect will clear my mind enough to get a handle on this later - i look forward to an eureka moment and then some more peaceful virtualmin.

Submitted by ashleydrees on Wed, 02/11/2015 - 04:42 Pro Licensee

The more i look at this it feels like something that the system has done is causing this failure - do you have a list of what cloudmin does during install so i can check through each one in my way to understanding this?

Submitted by andreychek on Wed, 02/11/2015 - 09:58

I'll talk to Jamie about this to see if he has any ideas -- but I can't think of what might cause that by installing Cloudmin. You can review what all is changed in the install.sh script that was used to perform the installation.

There is very little it does, other than just adding the Cloudmin module into Webmin.

It's common for people to install that on an existing server with Virtualmin, but I'll see if Jamie has any thoughts on whether LDAP could be playing a role here.

Submitted by ashleydrees on Thu, 02/12/2015 - 03:27 Pro Licensee

OK, i THINK i found something - which has brought the system back to where i thought it was / think it should be - but i am still not certain why this suddenly raised its head.

IN /etc/ldap.conf i have

nss_initgroups_ignoreusers backup,bin,bind,clamav,daemon,debianspamd,dovecot,dovenull,
ftp,games,gnats,greylist,irc,landscape,libuuid,list,lp,mail,man,messagebus,mysql,news,opendkim,
openldap,postfix,postgres,postgrey,proftpd,proxy,root,sshd,sync,sys,syslog,uucp

at the end of that ignore i used to have www-data... which is why the lookup did not work for www-data but did for domain admin users... i have had that in there since i built the system 6 months ago.. i have checked the backups, so something happened at that last reboot which probably corrected a permissions issue in the previous apache/kernel.

This will teach me not to do more than one thing at a time before a reboot. Thanks for putting up with my drivel. it really helps having to write it down, if i cannot explain a problem sensibly to a third party, there is no chance i can find the issue myself.