Posts tagged ‘linux’

Fun with hping3

I was bored so decided to play with hping3 a bit tonight.

[jlgaddis@bertram:~]$ sudo hping3 --udp -p 10000 --destport 10000 --flood 192.168.1.12
HPING 192.168.1.12 (eth0 192.168.1.12): udp mode set, 28 headers + 1400 data bytes
hping in flood mode, no replies will be shown

I have the same thing running 192.168.1.12 as well, for “bi-directional” traffic.

c1811# sh int fa7 | in put\ rate
  5 minute input rate 96657000 bits/sec, 8404 packets/sec
  5 minute output rate 93537000 bits/sec, 11389 packets/sec

rpmdb: Lock table is out of available locker entries

This morning, I received an e-mail from a cronjob on one of my production RHEL 5.2 servers:

From: Cron Daemon
To: Jeremy L. Gaddis
Cc:
Subject: Cron <root@SERVERNAME> run-parts /etc/cron.weekly

/etc/cron.weekly/makewhatis.cron:

rpmdb: Lock table is out of available locker entries
rpmdb: Unknown locker ID: b4a0
error: db4 error(22) from db->close: Invalid argument
error: cannot open Pubkeys index using db3 - Cannot allocate memory (12)

...

There were probably a couple hundred errors in that e-mail. In addition, I also received an e-mail from our RHN Satellite Server letting me know that this particular server had failed to check in. Logging in, I saw that, indeed, it had not been checking in with the our satellite.

So, what to do? Google, of course! Fortunately, major over at Racker Hacker encountered this same issue about a year and a half ago and has already provided the fix for us:

[root@SERVERNAME ~]# tar cvzf rpmdb-backup.tar.gz /var/lib/rpm
[root@SERVERNAME ~]# rm /var/lib/rpm/__db.00*
[root@SERVERNAME ~]# rpm --rebuilddb
[root@SERVERNAME ~]# rpm -qa | sort # to make sure everything's okay

I wanted to verify that the cronjob would now successfully execute, so I invoked it manually:

[root@SERVERNAME ~]# sh /etc/cron.weekly/makewhatis.cron
[root@SERVERNAME ~]#

Success! It also seemed like a good time to go ahead and install the updates that were missing so I took care of those using yum.

Many thanks to major at Racker Hacker for the fix!

VMware Converter 4.0 Standalone Beta

From an e-mail I received Tuesday:

Hello Jeremy,

Thank you for your interest in VMware beta programs. Our upcoming release of VMware Converter 4.0 Standalone product includes many exciting enhancements that our customers have been requesting including P2V support for Linux and Win 2K8 sources, hot cloning enhancements as well as workflow automation enhancements. We are certain you will find participation in this beta program a valuable experience. We are looking forward to working closely with you during this beta program.

As part of this beta, we request you to extensively test several areas of feature enhancements including P2V support for Linux and Win 2K8 sources, hot cloning enhancements as well as workflow automation enhancements. Your active participation in this beta program is critical. We appreciate and value your efforts to install upon downloading the software and actively provide us with your valuable product feedback.

I’m just about (in the next week or so) to attempt to P2V a Red Hat Enterprise Linux 4 host over to ESX, so maybe I’ll give the new 4.0 beta a shot. Anyone used it yet, especially to P2V Linux hosts? I am, of course, interested in hearing feedback on it.

Configuring FreeRADIUS to support Cisco AAA Clients

In this demonstration, we’re going to install FreeRADIUS onto a CentOS 5.2 server and configure it to support AAA on Cisco devices.

“FreeRADIUS is the most widely deployed RADIUS server in the world. It is the basis for multiple commercial offerings. It supplies the AAA needs of many Fortune-500 companies and Tier 1 ISPs. It is also widely used in the academic community, including eduroam. The server is fast, feature-rich, modular, and scalable.” –FreeRADIUS home page

I’ve been using FreeRADIUS in production for a few years now, mostly to support wireless users. One of the benefits of FreeRADIUS — besides being open source, of course — is the numbers of backends one can use for authentication:

“If a password is not available locally for some reason, the server can pass the authentication to another system such as LDAP, PAM, Unix (/etc/passwd), Kerberos, Active Directory, or RADIUS server via RADIUS proxying. Local programs (e.g. CGI scripts) can also be used to authenticate users via shell scripts or any other method. Perl or Python scripts can be pre-loaded into the server, which significantly lowers the cost of running such programs.”

Powerful, huh? Indeed.

For this demonstration, I’m installing a new CentOS 5.2 virtual machine on my MacBook under VMware Fusion. Installing the operating system, however, is beyond the scope of this document. Also, we’ll just be using the local system database for now — we’ll save SQL and LDAP (perhaps even Active Directory) authentication for later. After we get FreeRADIUS up and running, we’ll set up a user account and then configure a Cisco router to use RADIUS for authentication.

Let’s begin with installing FreeRADIUS by running (as root) the following command:

[root@bertram ~]# yum -y install freeradius

“yum” should have went out, grabbed the appropriates packages and dependencies, and installed them. If the end of your output looks like this, you’re all set:

Complete!
[root@bertram ~]#

Because FreeRADIUS will need to use the local system database for authentication, we need to set ‘user = root’ and ‘group = root’ in radiusd.conf. This is easy enough, just open up /etc/raddb/radiusd.conf, and change the lines that reads “user = radiusd” and “group = radiusd” to “user = root” and “group = root”, respectively. Note that this (running our daemons as root) is almost always something we want to avoid. Using other authentication backends, such as SQL or LDAP, would not require this change and would allow the FreeRADIUS service to run under the default “radiusd” unprivileged account.

Next, we need to let FreeRADIUS know about our NAS — in this case, our Cisco router. For the sake of this demonstration, our router (R1) will have IP address 192.168.1.201. We’ll also need a shared secret that the router and RADIUS server use. Let’s use the ever popular “SECRET_KEY”. Add the following to the end of /etc/raddb/clients.conf:

client 192.168.1.201 {
        secret = SECRET_KEY
        shortname = R1
        nastype = cisco
}

Then, on the FreeRADIUS side, we need to create a user account in the local user database that we’ll use for actually authenticating to R1. Nothing special here, just creating a new user account and setting the password. I’ve passed the plain-text password into “passwd” via stdin so that you can see it. Normally, we wouldn’t do that — just run “passwd cisco” and enter the password when prompted:

[root@bertram ~]# /usr/sbin/useradd cisco
[root@bertram ~]# echo secret | passwd --stdin cisco
Changing password for user cisco.
passwd: all authentication tokens updated successfully.
[root@bertram ~]#

We now have a local user named “cisco” with a password of “secret” that we’ll use when it comes time to authenticate to R1. Before we can do that, however, we must let FreeRADIUS know about the user. Append the following to /etc/raddb/users:

cisco   Auth-Type := System
        Service-Type = NAS-Prompt-User,
        cisco-avpair = "shell:priv-lvl=15"

This notifies FreeRADIUS of a local user account named “cisco”. Using the “cisco-avpair” attribute in this manner allows us to automatically assign privilege level 15 to the user, removing the requirement for the user to issue “enable” (and the enable secret) in order to gain elevated access.

Let’s get started configuring R1. I’m going to assume that you’re starting from a default configuration. The first thing we want to do is create a “fallback” user account (on the router itself) that we can use to authenticate if, for some reason, connectivity to the RADIUS server is lost. Let’s create a user named “admin” with a password of “letmein”:

R1(config)#username admin privilege 15 secret letmein

Under normal circumstances, we’ll never use this local account — only when the RADIUS server is unavailable.

The first thing I need to do is configure my interface on R1 and verify we can ping the RADIUS server. Assuming you already have your router up and running, you can likely skip this step:

R1(config)#interface fastethernet 3/0
R1(config-if)#ip address 192.168.1.201 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#
*Mar  1 00:10:14.635: %LINK-3-UPDOWN: Interface FastEthernet3/0, changed state to up
*Mar  1 00:10:15.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up
R1(config-if)#do ping 192.168.1.51

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.51, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/11/24 ms
R1(config-if)#

Excellent, all set! Let’s start configuring R1 for AAA:

R1(config)#aaa new-model
R1(config)#radius-server host 192.168.1.51 auth-port 1812 acct-port 1813 key SECRET_KEY

AAA should now be enabled on R1. Note that we provided the IP address of the RADIUS server as well as the shared secret we configured in FreeRADIUS earlier. In addition, we must specify the “auth-port” and “acct-port” used by FreeRADIUS, as these are different from Cisco’s defaults (1645 and 1646). Let’s configure authentication:

R1(config)#aaa authentication login default group radius local
R1(config)#line vty 0 4
R1(config-line)#login authentication default
R1(config-line)#line con 0
R1(config-line)#login authentication default

Here, we’ve told R1 to use RADIUS for authentication and to fall back to the local user database if the RADIUS server is not available. We don’t want to DoS ourselves!

The following command will allow the user to run an “exec” shell when logging into the router:

R1(config)#aaa authorization exec default group radius if-authenticated 

Last, but not least, we want accounting (the final “A” in “AAA”):

R1(config)#aaa accounting exec default start-stop group radius
R1(config)#aaa accounting system default start-stop group radius

That should be enough to allow us to login with our local (Linux) system account “cisco” that we created earlier. Let’s give it a shot:

macbook:~ jlgaddis$ telnet 192.168.1.201
Trying 192.168.1.201...
Connected to 192.168.1.201.
Escape character is '^]'.


User Access Verification

Username: cisco
Password:

R1#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
Ethernet0/1                unassigned      YES unset  administratively down down
Ethernet0/2                unassigned      YES unset  administratively down down
Ethernet0/3                unassigned      YES unset  administratively down down
Serial1/0                  unassigned      YES unset  administratively down down
Serial1/1                  unassigned      YES unset  administratively down down
Serial1/2                  unassigned      YES unset  administratively down down
Serial1/3                  unassigned      YES unset  administratively down down
FastEthernet3/0            192.168.1.201   YES manual up                    up
R1#exit
Connection closed by foreign host.
macbook:~ jlgaddis$

Success! We’ve installed FreeRADIUS, added a local user account, set up the NAS client (R1) and configured it to authenticate against the RADIUS server. Let’s take a look at what was logged by FreeRADIUS:

[root@bertram ~]# cat /var/log/radius/radacct/192.168.1.201/detail-20081119
Wed Nov 19 00:24:47 2008
        Acct-Session-Id = "00000005"
        User-Name = "cisco"
        Acct-Authentic = RADIUS
        Acct-Status-Type = Start
        NAS-Port = 130
        NAS-Port-Id = "tty130"
        NAS-Port-Type = Virtual
        Calling-Station-Id = "192.168.1.49"
        Service-Type = NAS-Prompt-User
        NAS-IP-Address = 192.168.1.201
        Acct-Delay-Time = 0
        Client-IP-Address = 192.168.1.201
        Acct-Unique-Session-Id = "31b757fca2145e79"
        Timestamp = 1227072287

Wed Nov 19 00:25:14 2008
        Acct-Session-Id = "00000005"
        User-Name = "cisco"
        Acct-Authentic = RADIUS
        Acct-Terminate-Cause = User-Request
        Acct-Session-Time = 27
        Acct-Status-Type = Stop
        NAS-Port = 130
        NAS-Port-Id = "tty130"
        NAS-Port-Type = Virtual
        Calling-Station-Id = "192.168.1.49"
        Service-Type = NAS-Prompt-User
        NAS-IP-Address = 192.168.1.201
        Acct-Delay-Time = 0
        Client-IP-Address = 192.168.1.201
        Acct-Unique-Session-Id = "31b757fca2145e79"
        Timestamp = 1227072314

[root@bertram ~]#

If there’s interest, I may expand on this later to include huntgroups, multiple RADIUS servers, using MySQL for accounting, or even through some LDAP and/or Active Directory authentication into the mix. If you’re interested, please leave a comment below!

Upgrading DD-WRT on the Buffalo WHR-G125

While browsing through my archives tonight, my thoughts went back to the reliable little Buffalo WHR-G125 router/access point over in the corner. Back in January, I wrote about having issues with my MacBook’s wireless and upgrading to — at the time — the latest version of DD-WRT to see if it would help with the issues.

Many months have passed since then and the wireless issues have went away. Unfortunately, I don’t really remember when they went away. I’m not sure if it had anything to do with the firmware upgrade or not.

Regardless, I browsed over to the DD-WRT site again to see if there was newer firmware available. There was, so I decided to upgrade. Upgrading to the latest version was really easy:

[jlgaddis@cleveland ~]$ ssh root@ap
root@ap's password:
root@router:~# cd /tmp
root@router:/tmp# wget http://tinyurl.com/5qv69u
root@router:/tmp# write dd-wrt.v24_vpn_generic.bin linux

At this point, we have a few minutes to kill. The flash memory isn’t the fastest in the world, and it’ll take a bit to save the file to flash. Once it’s done and our prompt has came back back, we just need to reboot.

root@router:/tmp# reboot

Give the router a minute or two to reboot, and we should be able to login again:

[jlgaddis@cleveland ~]$ ssh root@ap
DD-WRT v24 vpn (c) 2008 NewMedia-NET GmbH
Release: 07/27/08 (SVN revision: 10011)
root@ap's password:
==========================================================

 ____  ___    __        ______ _____         ____  _  _
 | _ \| _ \   \ \      / /  _ \_   _| __   _|___ \| || |
 || | || ||____\ \ /\ / /| |_) || |   \ \ / / __) | || |_
 ||_| ||_||_____\ V  V / |  _ < | |    \ V / / __/|__   _|
 |___/|___/      \_/\_/  |_| \_\|_|     \_/ |_____|  |_|

                       DD-WRT v24
                   http://www.dd-wrt.com

==========================================================


BusyBox v1.11.1 (2008-07-27 16:20:53 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

root@router:~# exit
Connection to ap closed.
[jlgaddis@cleveland ~]$

hospital dumps exchange for linux-based clone

taking a page from the doctors at the moses taylor hospital, i.t. staff at the scranton, pa., facility last year diagnosed their messaging system and came up with an effective treatment that’s turned out to be a life saver.

the patient in this case was an aging microsoft exchange 5.5 environment that couldn’t support increased message loads and was going to cost a bundle to upgrade.

i love hearing stories like this.

[ read more... ]

using voip at home with asterisk?

i’m curious if anyone is using voip at home, with service from a commercial voip provider — and integrated with asterisk. i’m one of the younger generation who hasn’t had a home phone in almost two years. the last year that i had one was only so i could have dsl and a fax at home (for my business). i use my work-issued cell phone (blackberry) for all my phone calls (except when i’m in the office).

i’ve been toying with the idea of setting up an asterisk box at home lately. i don’t really need to, but when has need ever had anything to do with the reason a geek does something? because i wouldn’t really use it much, i’m looking for something cheap.

what i’d like to do is just use voip at home without being tied in to any vendor-specific hardware (i.e. if i switch providers, i still want to be able to use it), and to be able to purchase an “x minutes/month” plan. i want something that’ll integrate with asterisk and give me a fixed number of minutes per month for a fixed cost. i’d probably pick up a couple of cisco ip phones to use.

if i can get that working, i have another house in another town that i’d connect as well. it has dry dsl, so there’s no actual phone there (i’m only there once every few weeks). i’d put a cisco router in there, set up an ipsec vpn between that house and my primary residence, and put a cisco ip phone there as well (assuming the latency and jitter are okay).

i’ve briefly looked into broadvoice and packet8 and would be interested in any opinions or recommendations.

revisited: rhel + san + iscsitarget + microsoft initiator

i originally wrote the following on 23-may-2007:

i installed red hat enterprise linux 4.5 on an hp dl365 yesterday to test out iscsi.

we carved out some space on the san to use for the testing, 500gb to be exact. the dl365 has a qlogic fiber-channel hba in it, connected to the hp san at 4 gbps. the 500gb of storage shows up on the rhel box at /dev/sda. no partitions or filesystems were created on the device.

as far as i can tell, rhel does not include support for being an iscsi target, which i did not find out until after i had it installed. fortunately, i came across the iscsi enterprise target project on sourceforge. their wiki led me to martin’s “iscsi target howto on enterprise linux (rhel4)“. by following that, i was able to get the iscsi target up and running, exporting the 500gb on /dev/sda.

the next step was to connect to that storage space from a windows box. this test is sort of a proof-of-concept to see if we can get things to work the way we want — which means windows “clients”, or initiators, will be used. i found anze vidmar’s “going enterprise — setup your fc4 iscsi target in 5 minutes” wiki page, which details setting up an iscsi initiator on windows. i grabbed the microsoft iscsi software initiator version 2.04 and installed it on my windows xp workstation (a vista version wasn’t available, or i’d have went for that).

following anze’s instructions allowed me to get the windows xp client configured as an initiator in just a few moments, and i had a p: drive showing up as a local disk, with an ~500gb ntfs filesystem on it for all my storage pleasure. excellent!

unfortunately, we need some access controls in our environment. if or when this goes into production, all iscsi traffic will be on an isolated, private network. i’m a big fan of the layered security approach, however, so while an isolated, private network is a good start, i want to implement the authentication that iet and the microsoft initiator are supposed to support.

enter problem. =)

anytime i try to set up some credentials on the target side (using “incominguser username password” in the /etc/ietd.conf config file) and use those same credentials in the microsoft iscsi initiator, i get a simple “authentication failure” dialog box on the client/initiator side. unfortunately, there aren’t any log entries on the server/target side (that i noticed, anyway) to help provide any insight.

anyone ran into this before and have any suggestions? tia.

update: seems i didn’t have any credentials listed in the “global” section of the /etc/ietd.conf file, which is needed if you try to do authentication during the discovery phase (i was). added that in and now have authentication working across the board.

getting rid of bind’s “lame server” messages

if, like me, you run bind, then you’ve probably encountered the “lame server” error messages in your logs at some point.

to be honest, they’re really not errors. they’re more warnings than anything, because the problem is actually with the remote server and not yours.

nevertheless, they can really build up over time and i, personally, don’t really care to see ‘em. to keep them out of your logs altogether, put the following near the top of your named.conf, then reload/restart bind:

logging { category lame-servers { null; }; };

revisited: new linux server

i originally wrote the following on 23-dec-2004:

well, i finally got something i’ve been wanting for a while… a dedicated linux server at work.

for a while now, we’ve been running a not-too-critical service on linux and it’s been stable and reliable as hell, but it was running on an old 400 mhz desktop-class pc. finally, it had a hardware failure (i knew it was only a matter of time) and it happened, of course, on the first day of a three-day out-of-town trip for $work. $boss got it straightened out and got the hard drive moved to a new, more modern box, and i was able to tell him over the phone what to do to verify that everything was working properly.

anyway, shortly after that he asked me about a dedicated server, which i definitely wanted. so now we have an hp server running debian gnu/linux in the datacenter. this is a huge step for our campus, since up until now we’ve been primarily a windows-only shop (with the exception of an old novell box or two still lingering around). i like windows and while we never have a problem with the majority of our applications and services i’d love to be able to migrate whatever i can off of windows and onto linux. it’s so much more stable, has fewer problems, and i’m much more familiar with linux administration than i am windows administration.

i’ve been adding a few things to the server already and need to migrate that one $critical_service over, but that won’t be difficult. luckily, the semester is over and there aren’t many students around, since it will result in downtime. i know i hate when a service i’m relying on is down, so i do my best to minimize downtown for everybody else.

anyway, got me a new server. woohoo!

boy, how things change in three and a half short years.

when i started out at this organization, we had that one linux box and that was it. today, we host a number of web sites running apache on red hat enterprise linux. those sites are backed by mysql databases running on gentoo. authentication, authorization, and accounting on our wireless networks is handled by freeradius on red hat enterprise linux. in addition, we have a number of “internal” services and homegrown applications that run on linux servers as well.

more and more of our critical services and applications are running on linux, and windows can’t even come close to matching the reliability and stability of the operating system.

as an example, i have a debian gnu/linux box running syslog-ng that is the syslog server for all of our network devices. it’s uptime just surpassed 500 days. take that, windows!