My technical book collection has grown quite large, though there are only a few books I go back to time and time again. I just took Self Service Linux and Linux Kernel Development off my shelf, and am planning to re-read both books over the Thanksgiving holiday. Self Service Linux is hands down one of the best technical books I’ve ever read, and the level of detail the author goes into is astounding. If there is a book on your shelf that you keep coming back to time and time gain, please leave me a comment. I’m looking to expand out quite a bit in 2011, and am hoping to start formally studying software development and algorithms. Hope everyone has a killer holiday, and I look forward to hearing about your favorite books!
Having lived in a big city for the past 10-years of my life, I’ve encountered a number of unpleasant things when I’ve been out and about. A few weeks back I hit one of the most frustrating ones of my life when a nail punctured one my tires while I was running errands. This shouldn’t have been an issue, but alas my spare tire was on the low side and I didn’t feel comfortable driving with it. With no gas stations in sight the feeling of “oh crap” came over me.
After spending 30 minutes on the phone with my insurance company, the agent told me that my insurance policy included roadside assistance. Thank goodness! They showed up an hour later and filled my spare and changed out my flat. After thanking the assitance guy 50 times, I proceed to head to a automotive shop to get my flat tire patched.
This experience got me thinking about ways to prevent this in the future, and after doing a bit of research I came across the Wagan 400-Watt Power Dome EX jumpstarter with built-in air compressor. This nifty little device comes with a number of useful features:
– Built-in battery charger
– Air compressor
– Flash light
– USB charger
– AM/FM radio
I tested out the radio, light and air compressor after my unit arrived from Amazon, and they all worked as advertised. This past week one of my co-worker’s had a dead battery in her car, so I got to verify the jumpstarting feature worked. Jumpstarting her car worked flawlessly, and I have since stashed my powerdome EX in the trunk of my vehicle.
This crappy experience has taught me a couple of valuable lessons. Cars are just like servers. They fail when you don’t want them to, and sometimes the easiest problems become the most difficult ones to solve. I’m planning to pick up a few more gadgets for my car to avoid getting into a similar situation in the future! If you keep anything in your vehicle to help out with emergencies, please let me know! I’d like to be better prepared for future events.
With the help of various contributors, I’ve integrated some new features and a number of bug fixes to ssl-cert-check over the past couple of months. If you aren’t familiar with this tool, it’s a bash script that you can use to notify you prior to your certificates expiring. You can read more about the script by surfing over to the ssl-cert-check documentation page.
While preparing for my RHCE exam, I wanted to install of the system-config-* GUIs to see what functionality they provided. I used the yum groupinstall option to install the GNOME desktop:
$ yum groupinstall ‘GNOME Desktop Environment’
and then proceeded to add my preferred desktop environment to /etc/sysconfig/desktop:
$ cat /etc/sysconfig/desktop
Once these items were installed I ran ‘init 5’ and was greeted with the following message in /var/log/messages:
init:x respawning too fast, disabled for 5 minutes.
After reading through various logs and scripts, I noticed that the gdm display manager wasn’t installed. I thought groupinstalling the GNOME desktop would force a display manager to be installed, but alas that isn’t the case. To get everything working I fired up yum and installed gdm:
$ yum install gdm
Everything worked as expected once gdm was installed, and I could fire up the GUIs without issue.
I took the RHCE exam this past week, and was fortunate to pass both the RHCT and RHCE sections with a score of 100%. While I can’t discuss what was on the test, I figured I would share the process I used to prepare for the test. When I decided to take the exam, I picked up a copy of the Red Hat Certified Engineer Linux Study Guide and read it from cover-to-cover. Michael Jang did a great job with the book, and it shed some light on things I never use (e.g., Linux printing).
Once I finished reading Michael’s book I printed the RHCE objectives. For each objective I did the following:
1. Researched which packages are needed to support each objective.
2. Installed the software from a local yum repository I created.
3. Read through the configuration files for each service and looked up each directive to see what it did.
4. Configured the service and integrated it with my home network.
5. Broke the service various ways and tried to figure out what I needed to do to fix it.
6. Figured out how SELinux integrated with each service. Also did a lot of SELinux debugging!
I used two virtual machines to study with, one acting as a server and the other a client. The items listed above took quite a bit of time to master, but I can definitely say I’m a better admin because of it. I learned a bunch of new things about RHEL/CentOS, and can definitely troubleshoot things faster now. Best of luck if you decide to take the exam!
When it comes to firewalling services, NFS has to be one of the most complex to get operational. By default the various NFS services (lockd, statd, mountd, etc.) will request random port assignments from the portmapper (portmap), which means that most administrators need to open up a range of ports in their firewall rule base to get NFS working. On Linux hosts there is a simple way to firewall NFS services, and I thought I would walk through how I got iptables and my NFS server to work together.
Getting NFS working with iptables is a three step process:
1. Hard strap the ports the NFS daemons use in /etc/sysconfig/nfs.
2. Add the ports from step 1 to your iptables chains.
3. Restart the portmap, nfs and iptables services to pick up the changes.
To hard strap the ports that the various NFS services will use, you can assign your preferred ports to the MOUNTD_PORT, STATD_PORT, LOCKD_TCPPORT, LOCKD_UDPPORT, RQUOTAD_PORT and STATD_OUTGOING_PORT variables in /etc/sysconfig/nfs. Here are the settings I am using on my server:
Once ports have been assigned, you will need to restart the portmap and nfs services to pick up the changes:
$ service portmap restart
Stopping portmap: [ OK ] Starting portmap: [ OK ]
$ service nfslock restart
Stopping NFS locking: [ OK ] Stopping NFS statd: [ OK ] Starting NFS statd: [ OK ]
$ service nfs restart
Shutting down NFS mountd: [ OK ] Shutting down NFS daemon: [ OK ] Shutting down NFS quotas: [ OK ] Shutting down NFS services: [ OK ] Starting NFS services: [ OK ] Starting NFS quotas: [ OK ] Starting NFS daemon: [ OK ] Starting NFS mountd: [ OK ]
If you query the portmap daemon with rpcinfo, you will see that the various services are now registered on the ports that were assigned in /etc/sysconfig/nfs:
$ rpcinfo -p
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 10051 status 100024 1 tcp 10051 status 100011 1 udp 10053 rquotad 100011 2 udp 10053 rquotad 100011 1 tcp 10053 rquotad 100011 2 tcp 10053 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 udp 10052 nlockmgr 100021 3 udp 10052 nlockmgr 100021 4 udp 10052 nlockmgr 100021 1 tcp 10052 nlockmgr 100021 3 tcp 10052 nlockmgr 100021 4 tcp 10052 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100005 1 udp 10050 mountd 100005 1 tcp 10050 mountd 100005 2 udp 10050 mountd 100005 2 tcp 10050 mountd 100005 3 udp 10050 mountd 100005 3 tcp 10050 mountd
Next up, we need to adjust the appropriate iptables chains to allow inbound connections to the NFS service ports. Here are the entries I added to /etc/sysconfig/iptables to allow NFS to work with iptables:
# Portmap ports
-A INPUT -m state –state NEW -p tcp –dport 111 -j ACCEPT
-A INPUT -m state –state NEW -p udp –dport 111 -j ACCEPT
# NFS daemon ports
-A INPUT -m state –state NEW -p tcp –dport 2049 -j ACCEPT
-A INPUT -m state –state NEW -p udp –dport 2049 -j ACCEPT
# NFS mountd ports
-A INPUT -m state –state NEW -p udp –dport 10050 -j ACCEPT
-A INPUT -m state –state NEW -p tcp –dport 10050 -j ACCEPT
# NFS status ports
-A INPUT -m state –state NEW -p udp –dport 10051 -j ACCEPT
-A INPUT -m state –state NEW -p tcp –dport 10051 -j ACCEPT
# NFS lock manager ports
-A INPUT -m state –state NEW -p udp –dport 10052 -j ACCEPT
-A INPUT -m state –state NEW -p tcp –dport 10052 -j ACCEPT
# NFS rquotad ports
-A INPUT -m state –state NEW -p udp –dport 10053 -j ACCEPT
-A INPUT -m state –state NEW -p tcp –dport 10053 -j ACCEPT
Then I restarted iptables:
$ service iptables restart
Flushing firewall rules: [ OK ] Setting chains to policy ACCEPT: filter [ OK ] Unloading iptables modules: [ OK ] Applying iptables firewall rules: [ OK ]
In addition to the rules listed above, I have entries to track state (using the conntrack module) and allow established connections. If everything went as expected, you should be able to mount your file systems without issue. To debug issues, you can use the following steps:
1. Add a LOG statement to your iptables INPUT chain to log drop packets.
2. Run tcpdump -i
3. Run rpcinfo -p to see if the correct ports were assigned.
With just a few steps, you can get NFS working with iptables. If you have any suggestions or comments, feel free to leave me a comment! I’d love to hear folks thoughts on this.