Ispconfig ISPConfig Version: 3.0.5.1 Debian Wheezy Hi, I just discover 4 strange lines in my fstab: Code: cat /etc/fstab ... /var/log/ispconfig/httpd/domain1.tld /var/www/clients/client1/web57/log none bind,nobootwait 0 0 /var/log/ispconfig/httpd/domain2.tld /var/www/clients/client0/web61/log none bind,nobootwait 0 0 /var/log/ispconfig/httpd/domain3.tld /var/www/clients/client0/web77/log none bind,nobootwait 0 0 /var/log/ispconfig/httpd/domain4.tld /var/www/clients/client0/web78/log none bind,nobootwait 0 0 Same taht in this thread: http://www.howtoforge.com/forums/showthread.php?t=60864 It's in this bug repport too: http://bugtracker.ispconfig.org/index.php?do=details&task_id=2541 My questions: - Is it normal to have this lines ? - What is their utility ? - Can I umount and remove it safely ? Thank you in advance. Laurent
yes Shell-Users can access their logfiles. You can remove the bind-mounts. But there is no really reason. Beside this, i didn´t like the solution, too. See http://www.howtoforge.com/forums/showthread.php?t=60237 Not sure why, but on my servers neither the mounts are unmounted during shutdown nore mounted automaticly after reboot. Thank you in advance. Laurent[/QUOTE]
Hi florian030, Thanks for the answer, I didn't realize the interest for shell users. I was waiting for an answer before rebooting, so thanks! Laurent.
Then there must be something wrong with your OS setup. All mount points defined in /etc/fstab are mounted at boot time. I tested it here and it works finr on my servers.
Maybe.... my web-dir is on a drbd-volume with ocfs2 as the filesystem and the log-dirs are on local ext3-partition. I think, the entries in /etc/fstab are wrong, since the mount could not be done duringt startup. It´s only possible after the drbd/ocfs2-mounts are done.
The entries in fstab are correct. If you use filesystems which does not get loaded at a later time, you can add "mount -a" command in a rc file like rc.local which is executed after your network filesystem is loaded to mount all mountpoints that could not be loaded at boot time.
There is one error in the mounting when we remove the page entry in /etc/fstab gone but still mount is active until you restart the server.
I have same issue. I don't like that ispconfig edit my /etc/fstab, please tell me how to disable this feature. Also my clients does not have SSH access, why I should have this entry in /etc/fstab? There is also a big issue with this settings If you try to make a new dir inside the web folder you get Permission Denied even as root user! try this: Code: cd /home/www/clients/client1/web1 mkdir testdir touch testfile ispconfig is the stata of the art for hosting but i really dislike this issue introduced by 3.0.5.1 I don't want to go back to 3.0.4.x but please give me a solution to fully disable this feature. Thanks very much.
Is it working as intended that root user can't make dirs inside /home/www/clients/clientN/webN/ dir? Or it is a side effect of this /etc/fstab manipulation?
You can't modify the web dir because ISPConfig uses extended right management. Look for chattr or lsattr command on Google or Wikipedia. lsattr => ----i--------e-- ./web10 which means the web dir is immutable (cannot modify/delete its content).
Immutable bit is the first thing that I disable in ISPconfig. You can do that in System | Server Config | Web | Permissions | Make web folders immutable (extended attributes). In KVM Containers it's a good thing. In LXC/LXD/Docker/OpenVZ it's a bad thing. In regards to fstab and log folder mounting... It seems that in LXC containers it's a bad thing. At least for now. Maybe they will come up with a way to solve the "mount: block device /var/log/ispconfig/httpd/website is write-protected, mounting read-only" problem.
I'm curious what the problem symptoms are with OpenVZ? In checking, I have that option set, and I haven't noticed any problem (though I've had minimal ispconfig usage, too). Testing immutable attr in an OpenVZ container seems to work: Code: root@host-1:~# touch testfile root@host-1:~# chattr +i testfile root@host-1:~# lsattr testfile ----i--------e-- testfile root@host-1:~# rm testfile rm: cannot remove 'testfile': Operation not permitted root@host-1:~# chattr -i testfile root@host-1:~# rm testfile root@host-1:~# I'm using ploop filesystem for these containers. It looks like the older simfs does have problems with immutable attribute, and could sure interpret this bug report to say that immutable is disabled: https://bugs.openvz.org/browse/OVZ-6573 But it doesn't act disabled.
I use openvz for my servers as well and did not notice any issues yet. This does not mean that there can not be issues, I just did not encounter any problems yet.
If you are using NAS/SAN there are minimal problems. If you try rsync:n data between servers or clusters you run in to problems with inodes. Just try to migrate/move an ISPconfig OpenVZ container that has a couple hundred immutable bit folders enabled You will curse the day! You will probably end up formatting the old storage rather than trying to manually delete the old immutable bit folders. Distributed storage is the name of the future. Prepare.
Hi, i had the same problem with this mounted logfiles.When they was mounted my server couldn't start but error loging ran fine. When i comment(with #) in /etc/fstab my server can start but error logging doesn't work for the websites. Any idea?
Do the lines have "_netdev" inside? If yes, try to remove that and then login to ispconfig and disable the network filesystem option in the server settings so that it does not get added again.
