5

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.

Improve this question

2 Answers 2

Reset to default
2

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.

Improve this answer
5
  • 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.
    – user163490
    Mar 8, 2013 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, 2013 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?
    – user163490
    Mar 8, 2013 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, 2013 at 1:56
  • That is not an answer of what the OP asked though.
    – ABu
    Oct 7, 2017 at 0:09
3

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
Improve this answer
5
  • Replace one bad hack (symlinking core directories into /home) with another... it's a solution, but not a great one.
    – voretaq7
    Mar 8, 2013 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, 2013 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, 2013 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, 2013 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, 2013 at 16:28

You must log in to answer this question.