Unix Revolution

Issue : Removing a device, or replacing a device with a different SAN LUN can be a bit challenging. HISTORY : Take this completely hypothetical situation, which may or may not happen to me quite frequently... your customer asked for 3 x 64 and 1 x 16 Gig LUNs... and for some reason the SAN admin assigns 4 x 64 Gig LUNs. You don't know this until you scan the bus and see them from the OS. At which point you have to tell the SAN admin that you need to replace 1 of the 64 Gig LUNs with a 16 Gig. And you also ask the admin to let you know when he/she removes the incorrect LUN so you can do your procedure to then remove the device from the OS view, and then he/she can proceed with adding the 16 Gig. Well, inevitably you will end up with syslog complaining about a SAN device no longer being available and the fun begins (this is because the admin removed the 64 and added the 16 probably in the same keystroke, or click of a button and this will not give you an opportuntiy to str

As I was installing Windows Vista in a VM on my 5 year-old laptop, I was noticeably pleased with the way the install went, and the look-and-feel of the desktop when it was finished. Then... I thought about the fact that I had planned on installing Fedora Core 15 on this same laptop yesterday and decided just to update the Linux release that was installed because I like the Desktop on FC14 MUCH better than FC15. As I was pondering a write-up about all this I then realized how much I liked Snow Leopard over OS X Lion and how I almost wished I hadn't upgraded my Macs. 2010 was a good year for desktop managers, I guess.  2011... a step backwards? Oh well, back to installing VMware tools.

You will need to first do the following: Create Activation Keys (https://rhnsat.host.com/rhn/activationkeys/List.do) Then - on your RHNSAT host [root@rhnsat ~]# rhn-bootstrap --activation-keys 1-GetYourOwnKey --gpg-key /var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT --allow-config-actions --allow-remote-commands * bootstrap overrides (written): '/var/www/html/pub/bootstrap/client-config-overrides.txt' Values written: enableProxy '0' serverURL 'https://rhnsat.host.com/XMLRPC' proxyPassword '' proxyUser '' sslCACert '/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT' httpProxy '' noSSLServerURL 'http://rhnsat.host.com/XMLRPC' enableProxyAuth '0' useGPG 1 * bootstrap script (written): '/var/www/html/pub/bootstrap/bootstrap.sh' on the client wget http://rhnsat.host.com/pub/bootstra

The portmapper assigns each NFS service to a port dynamically at service startup time. How do I allow legitimate NFS clients to access the NFS server using RHEL / Fedora / CentOS Linux 5.x iptables firewall? You need to open the following ports: a] TCP/UDP 111 - RPC 4.0 portmapper b] TCP/UDP 2049 - NFSD (nfs server) c] Portmap static ports - Various TCP/UDP ports defined in /etc/sysconfig/nfs file. Configure NFS Services to Use Fixed Ports However, NFS and portmap are pretty complex protocols. Firewalling should be done at each host and at the border firewalls to protect the NFS daemons from remote access, since NFS servers should never be accessible from outside the organization. However, by default, the portmapper assigns each NFS service to a port dynamically at service startup time. Dynamic ports cannot be protected by port filtering firewalls such as iptables. First, you need to configure NFS services to use fixed ports. Open /etc/sysconfig/nfs, enter: # vi /etc/

[root@server9 opt]# vi /etc/sssd/sssd.conf Add the following at the bottom (may affect performance) Enumerate = True # getent passwd This will poll the server for a refresh, you can then [root@server9 opt]# getent passwd ... LDAP USERS WILL BE DISPLAYED ... [root@server9 opt]# yum list | grep openldap This system is not registered with RHN. RHN support will be disabled. openldap.x86_64 2.4.19-15.el6 @anaconda-RedHatEnterpriseLinux-201009221801.x86_64/6.0 compat-openldap.i686 2.4.19_2.3.43-15.el6 base compat-openldap.x86_64 2.4.19_2.3.43-15.el6 base openldap.i686 2.4.19-15.el6 base openldap-clients.x86_64 2.4.19-15.el6 base openldap-devel.i686 2.4.19-15.el6 base openldap-devel.x86_64 2.4.19-15.el6 base openldap-servers.x86_64 2.4.19-15.el6 base openldap-servers-sql.x86_64 2.4.19-15.el6 optional [root@server9 opt]# yum install openldap-clients [root@server9 opt]# ldapsearch -x -ZZ

Not necessarily a good approach for the real world, but a good way for the RHCE test, if they happen to ask... [root@desktop9 sysconfig]# iptables -I INPUT 1 -i lo -j ACCEPT [root@desktop9 sysconfig]# iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE [root@desktop9 sysconfig]# service iptables save iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ] [root@desktop9 sysconfig]# service iptables start iptables: Applying firewall rules: [ OK ] This will get you started with a iptables file which will work (and subsequently forward packets).

SElinux is much more involved than I originally had assumed. However, it should not be feared. # sealert -a /var/log/audit/audit.log [root@desktop9 audit]# ls -lZd /var/www/html/ drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/ user : role : type : sens : cat # audit2allow Command to convert audit log to policy updates to allow the tasks that were previously denied. append { selinux | enforcing } = 0 on the kernel line in grub IF... you happen to disable and re-enable SElinux, it will require a "relabel -RF" of the entire filesystem. I'm actually becoming enamored with SElinux... seriously cool stuff. To update your context, you should use # semanage fcontext -a and not just chcon. If you happen to do a restorecon using chcon, it will revert the content back to it's original intended context. # man -k selinux # man -k _selinux -- Check out this location # /etc/selinux/targeted/contexts/files # gesebool -a

I'm going to blog my exploits here. More to come...