Basic Filesystem Changes

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [1]
COIT20266 – Systems Security Administration
Basic Filesystem Changes
The default space allocated to our filesystem does not match the
requirements for our server. This guide steps us through the
process of changing the way our filesystem is sized.
Changes to filesystems present a significant risk to our system.
One small mistake can easily render our server inoperable. We
should always ensure that we can rebuild our server from scratch,
in case things go wrong. This would typically be done from a
backup of our server, but we cover backups a little later. Since
we are using a virtual server we can make use of the clone
function of VirtualBox which allows us to take an almost exact
copy of our server.
Assumptions
We have previously installed and run the Ubuntu Base server and
can login to it through the PuTTY SSH client.
Filesystem before
Before we make changes to our system we should always capture
enough detail to show the state of the system before the changes
are made. This allows us to check the changes we have made and
perhaps get back to the original configuration if things go wrong.
It is often wise to do only one change at a time.
We will be changing the filesystem, so we need to capture the
details of our current filesystem configuration. To do that, we
will simply capture the output of the ‘df’ command. Skim through
the man pages of the ‘df’ command before using it.
The ‘df’ command generates a report on the filesystem disk space
usage. To run df we enter the following command:
[email protected]:~$
df
COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [2]
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VG_01-root 305422 94513 195140 33% /
udev 122716 4 122712 1% /dev
tmpfs 49740 248 49492 1% /run
none 5120 0 5120 0% /run/lock
none 124344 76 124268 1% /run/shm
/dev/sda1 233191 12197 208553 6% /boot
/dev/mapper/VG_01-usr 596664 249500 316856 45% /usr
/dev/mapper/VG_01-var 337127 234264 85455 74% /var
/dev/mapper/VG_01-tmp 27761 1372 24956 6% /tmp
/dev/mapper/VG_01-home 420474 10532 388234 3% /home
The df commands ‘-h’ flag (human-readable), may make those block
sizes more meaningful.
[email protected]:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VG_01-root 299M 93M 191M 33% /
udev 120M 4.0K 120M 1% /dev
tmpfs 49M 248K 49M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 122M 76K 122M 1% /run/shm
/dev/sda1 228M 12M 204M 6% /boot
/dev/mapper/VG_01-usr 583M 244M 310M 45% /usr
/dev/mapper/VG_01-var 330M 229M 84M 74% /var
/dev/mapper/VG_01-tmp 28M 1.4M 25M 6% /tmp
/dev/mapper/VG_01-home 411M 11M 380M 3% /home
Looking at the output above, it should be obvious that our /var
directory (VG_01-var – 330M) is too small for our needs – it is
currently 74% used and we will be installing more software. We
will be creating users later in the course, however the size of
the /home directory (VG_01-home 411M) is well in excess of our
needs.
So without adding new disks to our virtual server we can rearrange
our filesystem to allow space for additional software
requirements.
We will be reducing the /home directory (VG_01-home) to 256M and
increasing the /var directory (VG_01-var) to use all the available
space.
Virtual machine clone
Taking advantage of the fact that we are using a virtual machine,
we can make a clone of our server so that if things go wrong when
we change our filesystem, we can simply go back to the original
server.
VirtualBox includes excellent, searchable help – access it via the
menu ‘Help/Contents’. Search for the topic ‘Cloning virtual
machines’ and read through it. Note well the detail about MAC

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [3]
addresses – we should know from pre-requisite courses that having
two hosts with the same MAC address is not something we want on a
network.
From reading the help we should be able to make the clone
ourselves. We must make sure to ‘Reinitialize the MAC address’
and make a ‘Full clone’. We will be altering the filesystem, so a
‘Linked clone’ would not be of any use in this case. Screen dumps
of the steps are provided below – use the same names and make sure
the server is shut down before starting:

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [4]
Make sure to use ‘Ubuntu Server’ as the name for the new virtual
machine and reinitialize the MAC address.

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [5]
Take note of the default Virtual Disk name – ‘Ubuntu Serverdisk1.vdi’ – this will be fine for our needs – it clearly numbers

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [6]
the disk and associates it with the virtual machines name.
Remember this for later.
We will now use the new cloned server and leave the original ‘Base
Ubuntu Server’ as a backup – we will be making more clones of the
‘Base Ubuntu Server’ later, so don’t make any more changes to it.
There is one issue that needs to be addressed with our newly
cloned server – the MAC address has been changed. Ubuntu does a
very good job of detecting hardware when it is installed. One of
the ‘features’ of detecting the hardware is that it records the
MAC address of the network card in a configuration file. We need
to remove this configuration file and allow Ubuntu to recreate it
with the new MAC address.
To remove the Network configuration file that records the MAC
address we need to start our
new server and login. The server
will take a little longer to start-up, as it tries to configure
the network card that we have effectively replaced.
Since the network card fails to be configured we cannot login to
our server using PuTTY so we need to login using the VirtualBox
interface.
If interested we can spend some time researching the details of
the configuration file that stores the MAC address, but for now we
simply need to remove it and move on. We will first view its
content to get a basic understanding of its purpose:
[email protected]:~$
cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x100e (e1000)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”08:00:27:3d:c7:e7″,
ATTR{dev_id}==”0x0″, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth0″
# PCI device 0x8086:0x100e (e1000)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”08:00:27:3f:d2:bf”,
ATTR{dev_id}==”0x0″, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth1″
We can see that it maps the original hardware MAC address with the
‘software’ label ‘eth0’. The second entry for ‘eth1’ is where the
‘new card’ has been detected, but no longer maps to ‘eth0’ which
is where the problems begin.
To remove the file, run the following command:

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [7]
[email protected]:~$
sudo rm /etc/udev/rules.d/70-persistentnet.rules
Once removed, we can shut down and reboot our new server. As it
reboots the new network configuration file will be created,
mapping the new MAC address to ‘eth0’.
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:03.0 (e1000)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”08:00:27:48:1c:c4″,
ATTR{dev_id}==”0x0″, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth0″
We should now be able to use PuTTY to login to our server;
however, since the MAC address has changed, if we are using DHCP
to allocate IP addresses, we may find that the IP address of our
server has changed. So we may have to update the IP address in
PuTTY to match our server. Review where we did this previously
and make the change as required. If problems are encountered,
please raise them on the course forum.
Things are never easy for a System Administrator – we wanted to
modify our filesystem and have had to re-configure our network…
Changing the filesystem
When we installed the Ubuntu Server we elected to use LVM –
Logical Volume Management. We now need to use specific filesystem
and LVM tools to make changes to our filesystem. We should read
through the man page for lvm so we have a good understanding of
the tools available.
First we should capture a snapshot of what our current
configuration looks like. To do this we can use the lvdisplay
command. If we redirect the output to a file we will have a copy
of the configuration. First view the output:
[email protected]:~$
sudo lvdisplay|more
To capture the output we redirect the output to a file. Make sure
we are in the ubuntu users home directory (/home/ubuntu):
[email protected]:~$
sudo lvdisplay > lvdisplay_before.txt
This will create a file /home/ubuntu/lvdisplay_before.txt with the
output from the lvdisplay command. Use vi to view the text file.

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [8]
From the textfile we can see that the logical volume
/dev/VG_01/var is part of the VG_01 volume group and is 340.00 MiB
in size. We can also see that the logical volume /dev/VG_01/home
is part of the VG_01 volume group and is 424.00 MiB in size.
To increase the size of /var we must first decrease the size of
/home. We must consider the correct order of changes to be made
to ensure we don’t overwrite existing filesystems. It would be a
good idea to write out a step-by-step list before making any
changes and checking it twice before proceeding.
Making a file system smaller is not something we would do very
often. Typically we would be making them larger. However it is a
good exercise to help understand filesystems. On a running server
the /home filesystem is mounted and is in use – it is the
directory we find ourselves in when we login. We should never
make changes to filesystems that are in use if the changes can
affect the files – shrinking a filesystem could prevent files from
being written to disk (the filesystem is growing), however
expanding a filesystem should be okay, as it has no effect on the
existing filesystem space.
So to reduce the size of the ‘live’ /home filesystem we need to
take it ‘offline’ – to do that we need to unmount it.
[email protected]:~$
sudo umount /home
this results in an error message:
umount: /home: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
Because the filesystem is in use, we cannot unmount it.
We can ensure the /home filesystem is not in use by starting our
server in ‘recovery mode’. This mode puts our server in ‘singleuser mode’ and logs us in as the root user. Note that many of the
services are not started in this mode.
To start our server in ‘recovery mode’ we need to restart it and
when the bootloader (GRUB) shows its menu briefly, press the down
arrow key to select ‘recovery mode’.
So shutdown the server and restart it. Watch the VirtualBox
interface carefully and press the down arrow key when the
following menu appears:

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [9]
Select the second menu item (recovery mode), press [Enter] and
allow the server to start. Notice that the start-up process is
different to what we normally see. We are now in ‘recovery mode’.
Remember we are in ‘single-user mode’ so changes must be made
using the VirtualBox interface.
We are presented with a different prompt:
[email protected]:~#
We are logged in as the root user!
We can test to see what file systems are mounted by simply typing
the ‘mount -l’ command – note that we do not need to use sudo when
we are logged in as root:
[email protected]:~#
mount -l
The list includes /home, so it has been mounted. We need it
unmounted so we can reduce its size:
[email protected]:~#
umount /home
Check that it is no longer in the mount list before proceeding.
COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [10]
When making changes to filesystems that contains files, we need to
first check that there are no errors on the filesystem. Read the
man page for e2fsck and then run the following command:
[email protected]:~#
e2fsck -f /dev/VG_01/home
All checks should pass. Any problems should be raised on the
course website.
Once the filesystem has been checked for errors we can resize the
filesystem to a smaller size. Read the man page for resize2fs and
then run the following command:
[email protected]:~#
resize2fs /dev/VG_01/home 256M
This has reduced the size of the filesystem which is contained
within the logical volume. We now need to reduce the size of the
logical volume. Read the man page for lvreduce and then run the
following command (heed the warning):
[email protected]:~#
lvreduce –size 256M /dev/VG_01/home
We can now re-mount the /home filesystem and check that it looks
okay:
[email protected]:~#
mount /home
[email protected]:~# cd /home
[email protected]:~# ll
It should contain the ‘lost+found’ and ubuntu users home
directories.
Check the size of the logical volume and the disk usage details
for /home.
We can now restart the server in normal mode, so reboot and login
using PuTTY. Note that when we restart our server it will stop at
the GRUB bootloader screen – this is normal behaviour after
running in ‘recovery mode’. Press [Enter] on the first menu item.
It should not stop at the menu on the next restart.
Make sure the /home filesystem has mounted correctly.
We now need to increase the size of /var. Since we are increasing
the size of a file system we *can* operate on a live system. We
will use similar commands to those that we used to reduce the
/home filesystem. First get the order right – we must increase
the size of the logical volume before increasing the size of the
filesystem:

COIT20266 Week3 Systems Security Administration
Basic Filesystem Changes [11]
[email protected]:~$
sudo lvresize –size 508 /dev/VG_01/var
Where did the 508 come from? Make sure to note it for our
assessment submission.
[email protected]:~$
sudo resize2fs /dev/VG_01/var
Note that the resize2fs command, if not given a size, will expand
to the full extent of the logical volume, which is what we want in
this case.
Check the changes to the logical volume and filesystem.
It is always a good idea to keep a hardcopy listing of the
filesystem configuration. If disks start going bad or a rebuild
is required it can be one of the most useful hardcopy lists to
have.