Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am working with a server running that has a 15GB root partition, a 1GB swap partition, and a 216.9GB home partition. Apparently, the server ran out of space on the root partition at some point and instead of extending it, a previous maintainer of the server moved the /usr/lib, /usr/share, and /usr/bin directories into /home/usr and made symlinks to the directories' new locations at their old locations.

The server is running Arch Linux 3.6.10-1. The root and home partitions each have an ext4 filesystem.

With the exception of small nuances such as having to explicitly tell find to follow symlinks while searching for a file in /usr, could this setup be problematic? I am especially concerned and curious about any security issues related to the setup.

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

There are two possible solutions I would consider here:

  1. Figure out what's filling up your root partition, and fix it.
    This is probably the right solution -- With a 15GB root partition (and a sane partition layout) you really shouldn't be filling up the root partition.
    Of course if the data is legit and the partitioning layout is not sane (e.g. /varis on the root partition) there's probably not much you can do about it.

  2. Rebuild the server with a sane partitioning scheme.
    If you've legitimately filled the root partition, or your partitioning scheme is not sane, you should rebuild the system with a more appropriate partition layout.
    This solution is pretty painful (you're going to have to back up your data, reinstall the system, and restore the data), but it will leave you with a clean machine that doesn't have symlinks or bind mountpoints hanging around where they shouldn't be, for you or some future admin to trip over later.

There are alternate solutions (like aim's suggestion of using bind mounts), but I would consider these to be stopgap measures to buy you time with the system operating while you plan for a real solution.

share|improve this answer
    
I cleaned up the root partition as much as possible by cleaning out /var (it is on the root partition.) I also removed unused libraries and programs from the /home/usr directories. Unfortunately, if I put the /home/usr directories back onto the root partition, the partition would only have about 1GB of free space (the /home/usr directories take up about 12.5GB and the root directory still has about 1.5GB of data on it.) I don't think 1GB is a safe amount of free space for the root partition, especially since it contains /var. –  paraxor Mar 8 '13 at 1:47
    
@EvanTeitelman If /varis on the root partition your partitioning scheme is definitely not sane - you can buy time with aim's solution, but plan on rebuilding this box –  voretaq7 Mar 8 '13 at 1:50
    
Would trying to resize the existing partitions and their filesystems and adding /var and /tmp partitions be a bad idea? Or should I just rebuild the partition table entirely? –  paraxor Mar 8 '13 at 1:55
    
@EvanTeitelman That depends on your current partition layout -- If you have the room to rearrange things and make the partition layout sane it's certainly an option (and it avoids the reinstall) –  voretaq7 Mar 8 '13 at 1:56
add comment

Use mount with bind option instead of symlinks and you wouldn't have such problems

To do so you can add a few line in your /etc/fstab (source ; french) :

/home/usr/bin        /usr/bin     none   bind    0       0
/home/usr/share      /usr/share   none   bind    0       0
/home/usr/lib        /usr/lib     none   bind    0       0

The general syntax :

/source              /destination none   [r]bind[,...] 0 0
share|improve this answer
    
Replace one bad hack (symlinking core directories into /home) with another... it's a solution, but not a great one. –  voretaq7 Mar 8 '13 at 1:12
    
@voretaq7 Well this helps a lot when you don't want to waste time on rebuilding a whole system. –  Cerber Jul 11 '13 at 18:23
    
@Cerber Like I mentioned in my answer, this may serve as a useful stopgap, but "supervised neglect" like this is a bad way to manage systems. Fixing it correctly now (when it's your choice) is better than hacking it, pretending it's really fixed, and then having it blow up and become an emergency later (with everyone screaming at you because production is down). Voice of experience talking... –  voretaq7 Jul 11 '13 at 19:35
    
@voretaq7 I should have mentioned earlier that it was, in my case, a "disposable" development VM, for which I don't want to waste time ;). –  Cerber Jul 12 '13 at 16:00
    
@Cerber yeah, in that case stopgap until you can "dispose" of the VM and rebuild it properly for the next time you need it :) –  voretaq7 Jul 12 '13 at 16:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.