Your Linux Guy .com

DNS can be a funny and unpredictable beast.

It is paramount that the DNS environment be stable and standardized in large environments, as well as small.  But in large environments particularly, you run into some weird happenings…  Like for instance, where an Active Directory exists separately from the DNS environment, the DNS world can sometimes get out of sync without all the AD controls.

So if you have an environment where you cannot be certain that all the “A” records for your parent domain are properly registered and represented, you might want to regularly check up on the domain’s records with a script.  I’ve tossed together a fairly simple script that prompts you for the parent domain name, an IP address of a reliable DNS server, and then it goes out and makes sure that all the hosts listed as “A” records for the parent domain are actually *up* and responding to ping…

Just copy/paste the following into a file, and chmod +x the file, and then run it.  Enjoy!

#!/bin/bash

echo "What is the domain name to check? (like example.com): "
read DOMNAME
echo ""
echo "What is an authoritative DNS server for that domain? (like 10.1.2.3): "
read AUTHDNS

for item in `nslookup $DOMNAME - $AUTHDNS| grep "Address:"| awk '{ print $2 }'|grep -v "#53"`; do echo "Checking $item... ";ping -q -c 2 $item > /tmp/lastitem.txt; temp="$?";if [ "$temp" == "1" ]; then echo $item is unreachable;fi; done

echo "...Done!"

I hope that helps someone out there…

This is a common problem for many folks around the Internet.  You do some sort of an upgrade in WordPress, and you lose your “Visual” tab in the editing page, or you lose your buttons, etc.; all you have left is the “HTML” editing option.

This seems to happen to me every once in a while when I do upgrades, too.  And it happened to me again today, while upgrading to 3.3.1.

And, like you, I do the fresh replacement of wp-admin and wp-includes, and it doesn’t do any good.  I check the error logs.  I check other browsers and versions.  I clear caches.  I do a few other things that I find in the WordPress blogs.  All to no avail.

Well, I’m here to remind you AND MYSELF that next time this happen, just restart Apache first (of course this might only apply to those that have the luxury of a self-hosted site).  If that doesn’t work, (and it probably will), *then* do all those other things.

It’s been a wild year for Your Linux Guy.  My world has changed, and I’m busier than I ever have been before.  But I’ll do my best to keep bringing mildly interesting, odd, geeky, Linux-based posts to you in 2012.

I want to thank you all for reading my blog; and more importantly, for those who contribute (comments, post topic suggestions etc.).

Thanks!

Here are some neat year-end stats about the blog for your entertainment…  These are the posts that got the most views in 2011:

• 1 What ever happened to unix2dos in SLES? 3 comments, originally posted April 2009
• 2 How can I disable the firewall on SLES? 1 comment, originally posted February 2010
• 3 Some Interesting Things About ZCM 11 2 comments, originally posted November 2010
• 4 How do I set up iFolder 3.8 on Opensuse 11.1? 24 comments, originally posted December 2009
• 5 iFolder 3.8 Change Local User Password Script… 10 comments, originally posted May 2010

Thanks again!  And Happy New Year!

I just couldn’t help myself!  I had to post this…

Unless you are a regular reader to this blog and were here anyway, I’m guessing you stumbled on it from a search because youre having a problem with the Jetpack plugin for WordPress.  Well, well, well.  Recently, I also forced myself to install the Jetpack plugin;  and as the old saying goes, “…if it were easy to do, it wouldn’t be worth doing.”

Anyway, after installing and enabling Jetpack, I got the error that is apparently quite well-known among the WordPress user community:

Jetpack could not contact WordPress.com: register_http_request_failed. This usually means something is incorrectly configured on your web host.

And like you, I did the requisite amount of Googling; I found a few things, tried a few things, and none of them fixed my problem.  However, once I stumbled on this WordPress Support Forum thread, I realized I might be on to something when I read the post from member “houldsworth1″ describing the disabling of SSL if “…your web server is incapable of sending outgoing requests over HTTPS (as opposed to HTTP).”

After thinking about it for a moment, I thought, “Hey, I bet my server is just old enough that this would be a problem for me, too.”  So I attempted the suggested fix and found that the changes recommended by houldsworth1 need a little massaging in order to work with the latest version.  It turns out that instead of just editing line 1290 in the older version, you now have to edit a couple lines (because the developers have put in some extra courtesy checks to help you).

To start out with, like houldsworth1 recommends, the file to edit is:

<WP-ROOT>\wp-content\plugins\jetpack\jetpack.php

…but instead of the exact recommended change, on line 1422 change add the “false &&” to make it look like this:

if ( false && $jetpack->use_ssl[$method] ) {

…and on line 1427, do the same to make it look like this:

if ( false && wp_http_supports( 'ssl' ) ) {

And presto!  Communication, and the setup completed.  It worked for me!

Now here’s a caveat or two:  you aren’t *supposed* to have to do this.  If you need to do this, it probably means your webserver is too old (or has something else wrong) and should be replaced.  Because after you implement this, the Jetpack plugin is calling home over an unsecured channel (non-ssl).

I use bash to do almost everything.  Even when I’m neck-deep in Windows and I need to solve a problem, my first thought is a bash script.

Recently, I was working in a large distributed enterprise that utilizes Microsoft KMS to manage the enterprise licensing.  For the most part, all was well, and the new Windows machines that came online were getting licensed and working perfectly.

However, there were a few locations that accidentally turned a few of the downstream location servers into sub-domain KMS servers by improperly installing the license, and some new workstations in that local DNS sub domain were finding, using, and becoming loyal to those errant KMS servers.  My job was to root out all the errant KMS servers.  To the bash!

First thing I did was make a list of the DNS sub domains into a file called “subdomains.txt”, with one per line like this:

sub1
sub2
sub3
...

And if you have a nameserver that you trust, then you can just call that file in a “for” loop like this:

for item in `cat subdomains.txt`; do nslookup -type=srv _vlmcs._tcp.$item.parentdomain.local 10.18.12.10 |egrep -e "_vlmcs" -e "service"|awk '{ print $7 }'>>kmsViolators.txt;done

…replacing parentdomain.local with your parent domain.  And then you can view the output file to see if you caught any “fish”.

You can make more sense out of the list of results with:

for item in `cat kmsViolators.txt`;do nmblookup -A $item;done

…and just to see if the KMS service is really still running on those machines (and not blocked)…. scan them like this:

for item in `cat kmsViolators.txt`; do nmap -sT -p 1688 $item;done |egrep -v -e "Starting" -e "Nmap finished" -e "STATE"

Then, if you found some violators in one (or more) of the sub domains, you might want to see if the DNS servers agree on the KMS server listings.  So to focus on just one of the sub domains and test against all listed DNS servers, you can do this:

for item in `nslookup -type=ns parentdomain.local |grep "internet address"|awk '{ print $5 }'`; do echo "For nameserver $item:";echo "----------------------------------";echo "";nslookup -type=srv _vlmcs._tcp.sub1.parentdomain.local $item;done >> sub1-nsResults.txt

…replacing parentdomain.local with your parent domain, and replacing sub1 with the sub domain you wish to more closely inspect.

Ten, analyze the results file and see if you indeed caught the “trophy fish”!

I got this question from reader Ren:  “…I am looking for an article that assumes you have a web server running already on opensuse 11.3, and a friend asks you to host his web site for him as well and that he already has his own domain name registered.  I would like the step by step guide to add the virtual hosting to my Opensuse 11.3 server to do that for him…”

Thanks for the question Ren; this one is a natural for me since I do it all the time!  There might be a million better ways to do it, but here’s how I do it:

DNS

First, you have to set up the DNS.  If your buddy has decided to service the domain names from the registrar or some other provider, just have him point the record for the site to your server.  Typically, for a simple buddy-type web hosting deal, I just have him set up an “A” record for the domain record itself, and a “CNAME” to point “www” to that “A” record.

If you are going to host the DNS records for your buddy, just do the same as above in your DNS server, but have your buddy point the DNS server pointer(s) to your server(s).

AppArmor

Since this is a Suse box, I have to mention this.  We’re about to do something custom, so make sure that you’ve either built a custom set of profiles for AppArmor, or that you’ve disabled it.  Guess which I prefer for testing.  Now guess what I prefer for production.  I’m not saying.

Apache2

Now,you need to set up the apache2 listener.  Of course I have some custom stuff in my main apache config files, but your question was all about easy add-on hosting.

Note that the main apache config file httpd.conf has a statement to “Include” everything in the folder /etc/apache2/vhosts.d/ folder with a *.conf extension.  So, whether you have all your virtual hosts in a single file or you have a separate file for each one, you simply need to add some lines in the correct *.conf file, somewhat like this:

<VirtualHost hostname:80>
ServerName yourlinuxguy.com
ServerAlias *yourlinuxguy.com
DocumentRoot /srv/www/htdocs/yourlinuxguy.com
ServerAdmin yourlinuxguy@yourlinuxguy.com
ErrorLog /var/log/httpd/yourlinuxguy.com-error_log
CustomLog /var/log/httpd/yourlinuxguy.com-access_log combined
</VirtualHost>

…where “hostname” matches a locally-resolvable host name ( meaning /etc/hosts); “Servername” reflects your instance that matches the DNS domain configuration; “Serveralias” allows any goofed-up host name that people enter to still work (especially if you put a DNS wildcard in place); “Documentroot” in my case as shown points to the standard Suse-style apache docs repository; and some other ancillary configs.  I should confess that I actually have a couple more lines in my instance directive for security, but I don’t want to reveal them here… sorry…

For content, just create a folder called:

/srv/www/htdocs/yourlinuxguy.com/

…that has an index.html file that says something like “Hello World” in it or something.  Of course, you already have permissions set on the folder structure, so that’s not a concern here now.

Logrotate

Don’t forget to rotate the logs!  Note that from the apache config section above, you can see that I keep my logs in a separate folder.  I prefer this method over just using the built-in apache logrotate directives, because this way I have one main logrotate directive handling every log in the folder, and I can easily control the filenames with a wildcard (multiple sites on this host, remember).  Here’s an example of my homemade /etc/logrotate.d/httpd file:

/var/log/httpd/*log {
compress
dateext
maxage 31
rotate 4
size=+1024k
notifempty
missingok
create 644 root root
postrotate
/etc/init.d/apache2 reload
endscript
}

Now, all you have to do is to restart apache with the command rcapache2 restart.
And once you point your browser at it, you should see your happy “Hello World” message, and your buddy will be happy.

A couple weeks ago, my mother-in-law (M.I.L.) — who runs Opensuse 11.3 on her desktop — had a power outage.  After the power came on, she called me to describe a weird error she was getting during boot-up.  And the second NFL pre-season game for my team had just kicked off….

She described some stuff about it asking for the root password for maintenance, and the messages right above that about initializing the swap on /dev/sda2 and /dev/sdb2.  Ah, it was all coming back to me;  this box has two hard drives, and I bet one of them is damaged or dead.  But, the worst part is that I could not remember the root password on that machine (yes, I built it).

So, I gave her the choice of either bringing it over to my house (excuse to see the grandkids, and I could fix it at halftime), or I could talk her through the process of “cracking” into the Opensuse and attempting to repair all the partitions until we either fix them all or find them totally dead.  She was game for the phone-based support, so we began (remember that all of this was over the phone so I was flying blind)…

1. First, I pre-instructed her that we were going to reboot, and when she would see the list of “kernels”, to just press the down-arrow to stop the clock count-down.  So, she did the Ctrl+Alt+Del, and upon reboot hit the up arrow then back down to the previously-selected PAE kernel.
2. Next, I told her that she was to begin typing the next line I told her, and it should automatically start filling in a line/box near the bottom.  I had her begin, but after the first couple characters I asked if there was a space before the first character or if she needed to add one, and the space was already there so we continued:  init=/bin/bash  (this line causes the boot process to forgo the normal initialization process, and just run a shell for you to use for maintenance.)
3. Once at the “pound sign” prompt, it was time to start hammering away at the repairs.  I told her to type in mount -o rw,remount /dev/sda3 (I always use a standard disk layout for home-based boxes, so I knew sda3 would be the / partition), and she got a message that it mounted with errors.  Ah-hah!
4. Next I had her un-mount the partition we just mounted with umount /dev/sda3 and move to aggressively repairing it with fsck -y /dev/sda3 (yes, I know, I know; you’re wanting to post a message about how I should never use the “-y” flag…  But we were moving through the first quarter of the game…).
5. Amazingly for me and M.I.L., the repair completed successfully!

So, she did another Ctrl+Alt+Del, and she was logging in before the second offensive series was done in the game.  So we have a happy M.I.L., and I barely missed anything in the game (well, it is pre-season, so there isn’t much to miss anyway, but there you go…)

It is the sad sign of an end of an era, and yet-more proof that I am old.

Apparently, I’m one of the few people left in the world that want a *printed* Linux magazine, making me a relic of a by-gone era.  I came to these realizations as I read through the email I got from Linux Journal, announcing that:

“The August 2011 issue marks our last print run for Linux Journal, but it is not our last edition.”

…and…

“Beginning with the September 2011 edition of Linux Journal, issue number 209, all subscribers will be offered Linux Journal Digital Edition.”

Of course, the email goes into great detail about how they didn’t *want* to do this, but they *have* to (for various reasons).  I guess the primary reason is cost and such, but nobody ever asked *me* if I’d be willing to pay more per issue to cover the increasing printing and distribution costs.

Honestly, I’m so frustrated that I’d un-subscribe if I hadn’t already paid in advance for like 10 years.

Now, I’m going to have to 1.) find *another* printed magazine to which I can subscribe (if there are any left), and 2.) struggle in the meantime with my horrible PDF reader app on my phone whenever I actually try and read the LJ digital issue.  I almost wish they would have partnered with someone like SafariBooksOnline.com or something, in order to be delivered in a mobile-friendly format, but I digress…

The thing is, I take my printed issues of Linux Journal (and some other printed magazines) everywhere I go when I anticipate having to wait:  Haircuts, doctor’s office, daughter’s dance class, etc.  In fact, many times during these waiting situations, my phone is monopolized with TMBG ABC’s or 123′s videos (if you’re not a parent, you probably won’t understand), and I end up being left with the print issues I brought.  So now it looks like my choices will be to read the useless magazines around the doctor’s office, or buy another appliance to play videos for my kids.  Argh.

None of those things are that big of a deal, I suppose; but the bottom line is that I *like* the printed magazine.  And now I’m going to look around and try to find another Linux Magazine in print (if there is one, any suggestions folks?).  And I guess this is what makes me old.

Drat.

I recently got this question from reader Niyati:

“Can you please guide for installing apache separately without disturbing the current version on sles.. if doing that risks the support issues.. Or any workaround to get the latest release running on sles server.”

I’ll bravely say this with 99% certainty:  Running a second instance of Apache on a SLES server should not compromise your support; especially if you keep it 100% separate.  Besides, if a support person complains, you can always just remove the second instance.

Anyway, here’s a way to install the latest good version of Apache2 (at the time of this writing) on a SLES 11sp1 server that *already* has a SLES-provided Apache2 instance running on it (installed via zypper).

I’m going to run this second instance of Apache on a secondary address, rather than an alternate set of ports; so, I need to bind that secondary IP address.  In my case, my machine is 192.168.1.23/24, and my interface is eth0, so I’ll add .24 for my new instance in real time, like this:

ifconfig eth0:1 192.168.1.24/24

Now, since I’m going to “build my own” Apache, rather than using a pre-built binary (for various reasons), I need to make sure I have the needed support software for compiling and such:

zypper in gcc gcc43 glibc-devel linux-kernel-headers

And it’s time to get the new Apache2 bundle:

mkdir /tmp/apache;cd /tmp/apache
tar zxvf httpd-2.2.19.tar.gz
wget http://www.alliedquotes.com/mirrors/apache//httpd/httpd-2.2.19.tar.gz
cd httpd-2.2.19/

And to get it installed:

./configure
make
make install

Note that since I didn’t specify the installation prefix, it got placed into /usr/local/apache2; so we go there to make some tweaks:

cd /usr/local/apache2/conf
vi httpd.conf

We need to change the Listen statement to reflect the secondary address, like this… Change:

Listen 80
…to…
Listen 192.168.1.24:80

Of course, there’s a ton more you can do with it, but this will get it up and running.

Now, if your *other* instance of Apache is consuming all configured addresses, you’ll need to limit it to just the original IP address rather than 0.0.0.0.

vi /etc/apache2/listen.conf

Change:

Listen 80
…to…
Listen 192.168.1.23:80

Now restart the original instance:

rcapache2 restart

…and a netstat -patune should show 192.168.1.23:80 instead of 0.0.0.0:80

Now restart the new instance:

/usr/local/apache2/bin/apachectl start

…and a netstat -patune should show both 192.168.1.23:80 (for the original instance) and 192.168.1.24:80 (for the new instance).

And with that, you’re up and running with two instances!  You can edit the content of your old instance in /srv/www/htdocs, and the new instance content in /usr/local/apache2/htdocs/.

Now, of course I’m not covering how to automate the startup, or to add SSL, or anything else; I’ve covered those things and many others here in this blog in the past.   Besides, those things are relatively easy to find around the ‘Net… Just like you found this.

Enjoy!