settings

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?

XenServer Switch Ports Configuration Best Practices

/ Christopher Paquin / Leave a comment

Old_switch
Finally I have found it! Citrix's XenServer switch configuration best practices document.

While everyone in the world has blog posts and documentation regarding how to set up and configure bridged networks in Xen, they hardly ever go into the physical switch configuration required.

This is the document that you will need to pass along to your friendly Network Administrator, as they will more than likely not be familar with networking for Xen as its much different from networking for Vmware ESX.

http://support.citrix.com/article/CTX123158

The contents of the document above are outlined below.

Change the following options on the switches for XenServer ports:

  1. Enable PortFast on XenServer connected ports.
    PortFast allows a switch port running Spanning Tree Protocol (STP) to go directly from blocking to forwarding mode by skipping the learning and listening modes. PortFast should only be enabled on ports connected to a single host. Port must be an 802.1q trunk port if you are using VLANS and the port must be in access mode.
    Ports used for storage should have PortFast enabled.
    Note    : It is important that you enable PortFast with caution, and only on ports that do not connect to multi-homed devices such as hubs or switches.
  2. Disable Port Security on XenServer connected ports.
    Port security prevents multiple MAC addresses from being presented to the same port. In a virtual environment, you see multiple MAC addresses presented from Virtual Machines to the same port. If you have enabled Port Security, it shuts down the port.
  3. Disable Spanning Tree Protocol on XenServer connected ports.
    Spanning Tree Protocol must be disabled if you are using Bonded or teamed NICs in a virtual environment. Spanning Tree Protocol should be disabled because of the nature of Bonds and NIC teaming, to avoid failover delay issues when using bonding.
  4. Disable BPDU guard on XenServer connected ports.
    BPDU is a protection setting part of the STP that prevents you from attaching a network device to a switch port. When you attach a network device, the port shuts down and has to be enabled by an administrator.
    A PortFast port should never receive configuration BPDUs.
    Note    : When BPDUs are received by a PortFast port, it indicates another bridge is connected to the port, and it indicates that there is a possibility of a bridging loop formation during the Listening and Learning phases. In a valid PortFast configuration, configuration BPDUs should never be received, so Cisco switches support a feature called PortFast BPDU Guard, which is a feature that shuts down a PortFast-enabled port in the event a BPDU is received. This feature ensures that a bridging loop is not formed, because the switch's shutting down the port removes the possibility of a loop forming.