Virtualmin fails to create virtual server

Submitted by airshock on Wed, 02/18/2015 - 14:54

Hi,

I am all of a sudden having problems creating a new virtual server in Virtualmin. The last time I created one was back in January and everything worked fine. I haven't made changes to Virtualmin at all since then, except enabling the Git plugin, but am now getting several errors upon server creation.

First, Virtualmin reports the following error at the "Performing other Apache configuration" step:

Configuration failed: failed to copy /etc/php.ini to /home/audioshout/etc/php5/php.ini

Then, Virtualmin reports this when "adding Git directives to Website configuration":

Git repositories failed: virtualmin-git::feature_setup failed: failed to open /home/audioshout/etc/git.basic.passwd: No such file or directory.

The virtual server gets created, though, but the "etc" and "fcgi-bin" directories are missing from the home directory.

I have no idea why this could be happening; do you perhaps have any ideas as to how I can resolve this issue? I am starting a project for one of my college classes and need to create a new virtual server to house its files.

Thank you, -Logan

Status: 
Active

Comments

Submitted by andreychek on Wed, 02/18/2015 - 15:22

Howdy -- what is the output of the following commands:

ls -l  /etc/php.ini
df -h
dmesg | tail -30

Those should help us determine what might be going on there. Thanks!

Submitted by airshock on Fri, 02/20/2015 - 07:56

Sorry for my late reply, but here is the output of the given commands:

Command: ls -l /etc/php.ini

-rwxrwxrwx 1 root root 69688 Jan 16 13:39 /etc/php.ini

Command: df -h

Filesystem Size Used Avail Use% Mounted on /dev/root 24G 6.1G 17G 27% / devtmpfs 495M 0 495M 0% /dev tmpfs 496M 0 496M 0% /dev/shm tmpfs 496M 52M 445M 11% /run tmpfs 496M 0 496M 0% /sys/fs/cgroup 192.168.182.197:/userdata 24G 4.0G 19G 18% /home 192.168.182.197:/httpd 24G 4.0G 19G 18% /etc/httpd 192.168.182.197:/php 24G 4.0G 19G 18% /opt/rh 192.168.182.197:/logs 24G 4.0G 19G 18% /var/log/virtualmin

Command: dmesg | tail -30

[8175832.734764] systemd-journald[1399]: Vacuuming done, freed 0 bytes [8175832.788912] systemd-udevd[1425]: starting version 208 [8175832.818018] EXT4-fs (xvda): re-mounted. Opts: grpquota,errors=remount-ro,usrquota,data=ordered [8175832.977076] audit: type=1305 audit(1424290698.518:2): audit_pid=1474 old=0 auid=4294967295 ses=4294967295 res=1 [8175833.018846] Adding 524284k swap on /dev/xvdb. Priority:-1 extents:1 across:524284k SSFS [8175833.956400] random: nonblocking pool is initialized [8175840.603675] systemd-journald[1399]: Received request to flush runtime journal from PID 1 [8175866.960715] Adjusting xen more than 11% (9436852 vs 9311354) [8175878.432044] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead. [8180894.499256] systemd-journald[1399]: Vacuuming done, freed 0 bytes [8186443.171858] systemd-journald[1399]: Vacuuming done, freed 0 bytes [8193335.391095] systemd-journald[1399]: Vacuuming done, freed 0 bytes [8200064.672348] systemd-journald[1399]: Vacuuming done, freed 0 bytes [8207146.696877] systemd-journald[1399]: Vacuuming done, freed 0 bytes [8212918.563044] systemd-journald[1399]: Vacuuming done, freed 0 bytes [8222290.677624] systemd-journald[1399]: Vacuuming done, freed 0 bytes [8229037.944561] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8236657.973545] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8241937.883687] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8248026.498356] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8255619.185414] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8263428.949496] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8271805.505167] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8281448.139319] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8287104.088275] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8292370.991141] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8298388.627984] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8303270.530558] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8311781.835402] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes [8323694.877151] systemd-journald[1399]: Vacuuming done, freed 6496256 bytes

Just to give even more info, I am running CentOS 7 (latest version), Apache 2.4.12, PHP 5.4.16 and 5.6.4 (/opt/rh/php56), MariaDB, Virtualmin 4.14 Pro.

Thank you, -Logan

Submitted by JamieCameron on Fri, 02/20/2015 - 12:49

Is the /etc/php.ini file readable by the domain owner user?

Submitted by airshock on Fri, 02/20/2015 - 16:14

It's actually owned by root, as indicated in the output of ls -l /etc/php.ini from my previous post. I haven't touched this file in a long time though, because PHP 5.6 is the default for new virtual servers, and it gets its INI file from /opt/rh/php56/root/etc/php.ini (I configured this in Virtualmin settings).

Submitted by andreychek on Fri, 02/20/2015 - 17:55

It looks like /home is being mounted from another server, perhaps via something like NFS?

One possible cause of what you're seeing is if the Virtual Server owner, or root, doesn't have permission to write to files/dirs on that remote filesystem.

What is the output of the command "mount"?

Submitted by airshock on Fri, 02/20/2015 - 20:17

Hi,

/home is indeed mounted on a different server via the Gluster file system. But it's always seemed to work well before this issue cropped up. I have a total of four servers, two of which are Gluster servers, one is the Virtualmin server (this one), and one is a secondary Web server that just runs Apache, PHP, MariaDB, and the Gluster mounts. The two Gluster servers are replicas of each other.

Here is the output of the "mount" command:

/dev/xvda on / type ext4 (rw,noatime,quota,usrquota,grpquota,errors=remount-ro,data=ordered) devtmpfs on /dev type devtmpfs (rw,relatime,size=506348k,nr_inodes=126587,mode=755) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=24,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) mqueue on /dev/mqueue type mqueue (rw,relatime) configfs on /sys/kernel/config type configfs (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) 192.168.182.197:/userdata on /home type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) 192.168.182.197:/httpd on /etc/httpd type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) 192.168.182.197:/php on /opt/rh type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072) 192.168.182.197:/logs on /var/log/virtualmin type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)

Thanks, -Logan

Submitted by JamieCameron on Fri, 02/20/2015 - 23:48

Do you have any settings on the glusterfs server side that might prevent root from accessing files? With NFS servers, there is a root_squash option that changes file accessed by root to be done with the permissions of the user nobody , which could cause the behavior you saw.

Submitted by airshock on Sat, 02/21/2015 - 09:07

Not that I know of. I have had this system in place since December without any issues from Virtualmin or other programs.

Submitted by JamieCameron on Sat, 02/21/2015 - 11:52

I guess you can test this by SSHing in as root and trying to copy /etc/php.ini into a domain's home directory.

Also, try the same thing when logged in as a domain owner user.

Submitted by airshock on Sat, 02/21/2015 - 15:30

Hi,

Here's what I did, based on your suggestion:

  1. I logged into the server via SSH as root and (after moving the existing php.ini file to a safe location) ran: cp /etc/php.ini /home/DOMAIN/etc/php5/php.ini (where DOMAIN is the virtual server username). Result: no errors, I can display the file just fine.

  2. I then logged into the server via SSH as a virtual server user, and ran the same command with no errors. The result was again that I could display the file just fine.

I have no idea why this won't work when Virtualmin tries to create a new virtual server. However, the server creation process does complete, i.e. everything else gets created except this stuff. In fact, after the server has been created and I browse to its home directory, the "etc" and "fcgi-bin" folders are missing.

Thanks, -Logan

Submitted by JamieCameron on Sat, 02/21/2015 - 19:29

I wonder if somehow the glusterfs server doesn't give newly created users permissions to access files...

Are you using LDAP to share users between your Virtualmin system and the glusterfs server?

Submitted by airshock on Sat, 02/21/2015 - 21:39

Hi,

I do use LDAP to share users across both my backend Web servers; my LDAP servers are hosted in a different data center though, so I connect across the Internet. However, the Gluster servers are not set up to use LDAP because they are only Gluster servers, so no other services run on them (like mail, Apache, etc.), therefore, nobody but root ever needs to log into them.

I have been able to create virtual servers as recently as last month without having any kind of issues, which is why this problem seems so odd.

Thanks, -Logan

Submitted by JamieCameron on Sat, 02/21/2015 - 23:51

The trigger may be changes in the recent Virtualmin release which improve security be changing the user file operations are done as, such as setting up the php.ini file. However, on our test systems this works fine.

Would it be possible for me to login to your system, create a test domain and see what is going wrong?

Submitted by airshock on Sun, 02/22/2015 - 13:40

Hi Jamie,

I have just e-mailed you instructions and credentials for accessing my Virtualmin server; feel free to pop in and troubleshoot this issue.

Thanks, -Logan

Submitted by JamieCameron on Sun, 02/22/2015 - 15:29

So I just logged in and created a test domain from the command line with :

virtualmin create-domain --domain jamietest.com --dir --unix --web --pass foo

and it copied the php.ini file just fine.

Submitted by JamieCameron on Sun, 02/22/2015 - 15:31

Also, I was able to create a domain from the UI with the default settings which also worked fine..

Submitted by airshock on Sun, 02/22/2015 - 16:30

OK, that's really weird....I just tried creating the virtual server that gave errors a few days ago, and it works perfectly now save for a log rotate error that says the file is already being rotated. I haven't made any changes at all to this system since the error happened a few days ago, so I don't know what could have caused or fixed the problem.

Submitted by JamieCameron on Sun, 02/22/2015 - 16:43

That is indeed odd - I can't imagine why this error would be transient, but it is hard to debug without seeing it happen :-(