fstab

Working With Extended Filesystem Attributes in Linux

/ Christopher Paquin

GarfatIn my previous post I went over standard filesystem attibutes in Linux, and how to set and view those attibutes with lsattr and chattr. You can view that post here if you are interested.

In this post we are going to go over extended filesystem attibutes. Now there is not much to this as you are probably not going to ever have to use these settings. That being said, its not a bad thing to be aware of.

Attribute names are strings that can be set and configured at will using the setfatr command. They can be viewed with the getfattr command. There are 4 namespaces of attibutes, security, system, trusted, and user.

When using getfattr ( which I pronounce as getfatter) the -d option dumps only user namespace attibutes. The rest of the namespace attributes can be viewed by using the -m option along with the namespace name. In the example below you can see that there are no user namespace attibutes set on my anaconda-ks.cfg file, however there are attibutes set in the security namespace.

[root@localhost ~]# getfattr -d anaconda-ks.cfg
[root@localhost ~]# getfattr -d -m security anaconda-ks.cfg
# file: anaconda-ks.cfg
security.selinux="unconfined_u:object_r:admin_home_t:s0"

 

Using setfattr you can define and set custom attributes. See the useless example below.

[root@localhost ~]# setfattr -n user.example -v example anaconda-ks.cfg
[root@localhost ~]# getfattr -d anaconda-ks.cfg
# file: anaconda-ks.cfg
user.example="example"

However this could be cool if you got an md5 sum on a file and dumped it into a file attibute. You could, in theory, use this process to see if someone has messed with one of your config files.

 

[root@localhost ~]# md5sum anaconda-ks.cfg
fda1aa550d3cf82423d1b1ad1ae53a13  anaconda-ks.cfg
[root@localhost ~]# setfattr -n user.md5sum -v fda1aa550d3cf82423d1b1ad1ae53a13 anaconda-ks.cfg
[root@localhost ~]# getfattr -d anaconda-ks.cfg
# file: anaconda-ks.cfg
user.example="example"
user.md5sum="fda1aa550d3cf82423d1b1ad1ae53a13"

 

Related articles

Why Extended Attributes are Coming to HDFS
Advanced Filesystem Attributes in Linux
How to create a file that root user also can't delete?

RHEL6 – Quick and Dirty NFS How To

/ Christopher Paquin / 3 Comments

Cobra1So if you are reading this you many not be aware of the fact that I already put up a post on NFS on RHEL6 (you can find it here). However that post is basically just a redirect to another blog post that I ran into on the subject. And despite the fact that its very well written, and has no apparent spelling mistakes, or inapropriate comments about NFS, I felt the need to draft my own post. At this point I really cannot seem to remember anything technical if I don't put up a blog post on the subject. After all I have been doing so for over 4 years, so why stop now.

Anyway, now that I got all that out of the way, lets sit down on brass tacks.

First lets create a directory to be shared on our NFS Server

# mkdir -p /shared/nfs

Now lets change the unix perms so that its wide open

# chmod 777 /shared/nfs

Now lets add our new nfs share to /etc/exports/. In this example I am sharing it out to my local /24 network.

/shared/nfs     10.1.224.0/24(rw,sync)

 Now restart NFS service

# service nfs restart

Now verify that you are now sharing via NFS with showmount

# showmount -e localhost

Export list for localhost:
/shared/nfs 10.1.224.0/24

If you are running iptables on your nfs host you are going to need to do a bit more to get nfs to work

If you go by the book, you are going to need to run to open several ports, the commands below will open up what you need.

# iptables -I INPUT -m multiport -p tcp –dport 111,662,875,892,2049,32803 -j ACCEPT

# iptables -I INPUT -m multiport -p udp –dport 111,662,875,892,2049,32769 -j ACCEPT

The fast and cheap way is to just allow all from your nfs client

# iptables -I INPUT -s 10.1.224.55 -j ACCEPT

Now lets go over to the host that we intend to mount our nfs filesystem on and run our showmount command again

# showmount -e 10.1.224.34
Export list for 10.1.224.34:
/shared/nfs 10.1.224.0/24

Now manually mount your share as seen below

mount -t nfs 10.1.224.34:/shared/nfs /mnt

Now add your share to /etc/fstab so that its mounted persistently across reboots.

10.1.224.34:/shared/nfs /mnt                    nfs     defaults        0 0

Just to be sure that everything is correct, unmount /mnt and mount /mnt. This way you will catch any errors in your fstab. Probably not a bad idea to touch a file under your new nfs mount too, just to make sure that its writeable.

RHEL- Find UUID of Hard Disks

/ Christopher Paquin / Leave a comment

CinderblockAnyone who has added and removed multiple disks from a RedHat server knows very well that your disks may not always enumerate exactly the same way after a reboot. You then have to resort to mounting up your filesystems to a temporary mount point to see exactly whats in them, and were they really need to be mounted.

Want to know if UUIDS are being used on your linux box, well just cat /etc/fstab, and if you see somthing similar to what’s below, then you are using UUIDS, instead of traditional disk device names.

UUID=3fa4603e-9874-4f47-ae1c-3f7715a54238 /                       ext4    defaults,user_xattr        1 1
UUID=483c34a4-b3ec-4860-854f-b9e5b6a6efac /boot                   ext4    defaults        1 2
UUID=7cab6648-b3f3-4aaa-bb2b-d32b78156aab /var                    ext4    defaults        1 2
UUID=7b05f0a9-18d5-42e5-b259-78ba3a8cc1b7 swap                    swap    defaults        0 0

One way of mapping device UUIDS back to device names is the blkid command — usage and output below.

[root@fedora15 ~]# blkid
/dev/sda1: UUID=”483c34a4-b3ec-4860-854f-b9e5b6a6efac” TYPE=”ext4″
/dev/sda2: LABEL=”_Fedora-15-x86_6″ UUID=”3fa4603e-9874-4f47-ae1c-3f7715a54238″ TYPE=”ext4″
/dev/sda3: UUID=”7b05f0a9-18d5-42e5-b259-78ba3a8cc1b7″ TYPE=”swap”
/dev/sdb1: UUID=”7cab6648-b3f3-4aaa-bb2b-d32b78156aab” TYPE=”ext4″
/dev/sdb2: UUID=”rJfNaK-e3Xp-n3qm-4aXM-BfKF-g7sg-Kwm33a” TYPE=”LVM2_member”
/dev/sdc1: LABEL=”raid1″ UUID=”34ed4ffd-cc4a-4b40-892f-6d7714fe7f4e” TYPE=”ext3″
/dev/mapper/vm_vg-v1: UUID=”2d96aa43-b5b8-4185-8014-323ad8a07a0d” TYPE=”ext4″

You can also do an ls on the following directory and get the same information.

[root@fedora15 ~]# ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Sep 25 21:41 2d96aa43-b5b8-4185-8014-323ad8a07a0d -> ../../dm-0
lrwxrwxrwx 1 root root 10 Sep 25 20:51 34ed4ffd-cc4a-4b40-892f-6d7714fe7f4e -> ../../sdc1
lrwxrwxrwx 1 root root 10 Sep 25 20:51 3fa4603e-9874-4f47-ae1c-3f7715a54238 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 25 20:51 483c34a4-b3ec-4860-854f-b9e5b6a6efac -> ../../sda1
lrwxrwxrwx 1 root root 10 Sep 25 20:51 7b05f0a9-18d5-42e5-b259-78ba3a8cc1b7 -> ../../sda3
lrwxrwxrwx 1 root root 10 Sep 25 20:51 7cab6648-b3f3-4aaa-bb2b-d32b78156aab -> ../../sdb1

If you are so inclined, you can also get the UUID and filesystem label (if there is one) with the tune2fs command

tune2fs -l /dev/sda1

Filesystem volume name:   <none>
Last mounted on:          /boot
Filesystem UUID:          483c34a4-b3ec-4860-854f-b9e5b6a6efac
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)

….truncated…

Oh and if you are running Fedora 15 and are wondering what the heck rootfs is (as I was), here is an explanation. More junk that I hope never gets into RHEL.

Oh and if you are really bored, and would like to know more about what a UUID is go here