Friday, December 22, 2006

how to coerce OMSA 5.1 to install & run properly on CentOS 4 (part III)

Here is the summary of what I did for OMSA 5.1 on CentOS 4.1 ( the white-box twin of RHAS 4.1)

For installation, on a CentOS 4.1 without OpenIPMI or net-snmp, you just need to
  1. append /etc/redhat-release with "Nahant", RHEL 4's code name.
1c1
< CentOS release 4.1 (Final) Nahant --- > CentOS release 4.1 (Final)
2. start installation by running ./linux/suppportscripts/srvadmin-install.sh
After installation, answer NO to start start all services. Instead, conduct the following steps first:
1. insert a line 'test -e /dev/ipmi0 || mknod -m 0600 /dev/ipmi0 c 253 0' at the beginning of /etc/init.d/dsm_sa_ipmi. w/o it, /etc/init.d/dsm_sa_ipmi will fail miserablly. It seems that udev doesn't put /dev/ipmi0 back as expected.
22,24d21 < # my hack < test -e /dev/ipmi0 || mknod -m 0600 /dev/ipmi0 c 253 0 < #
2. insert '/etc/init.d/dsm_sa_ipmi start' at the beginning of 'start' section inside /usr/bin/srvadmin- services.sh
w/o it, srvadmin-services.sh start will fail with IPMI drivers fail to load. However, if you start IPMI manually by '/etc/init.d/dsm_sa_ipmi start', you'd be just fine.
241,243d240 < # my hack::ipmi failed to start when called from later this script < /etc/init.d/dsm_sa_ipmi start <
3. now start it all with /usr/bin/srvadmin-services.sh start
4. verify it with ' omreport chassis temps' and 'omreport storage controller '. These two rely on different things to work. I'll elaborate on this later.

The rc scripts are placed in the S50 instead of their own start sequence number mandated in the scripts. I corrected them manually with my understanding of chkconfig directives in the scripts. However, I didn't get to change run level to test whether that would guarantee OMSA startup succesfully, since all my boxens are in production. Besides, Hobbit Monitor will let me know soon enough upon such failure.

It is such a great relief to have constant & comprehensive monitoring against critical systems. As a system engineer, you don't have to make all these mental or paper notes to check this or that. A decent NMS will do its job to nag you (whether you like or not) when necessary.

Wednesday, December 20, 2006

how to change IP address on a Linux server :: a project?

I was asked this question once, "how do you change IP address on a Linux server?"  At its face value, it's a simple technical question on systems administration or network administration using a Linux server. So, my instant response is
  • edit /etc/sysconfig/ifcfg-eth0 (or eth?).   or system-config-network TUI or GUI.
  • adjust routes and personal fw on the host as needed
  • ifconfig eth1 down && ifconfig eth1 up (or /etc/init.d/network restart)
  • verify: ifconfig eth1 (to see if the new IP has taken effect)
  • check & verify from remote host it is actually accessible (TCP/IP level, plus other services the server may provide)
  • update DNS if applicable
To dwell on the question a little more,  and depends on the context of the conversation, the lines of questions, and who asks, I would expand a bit from the perspective of process management, configuration management, and knowledge management. In other words, I'd prefer to drive such a "simple" change as a small project. Thus, here comes the addition to my initial answer:

So, the actual change is simple. Depends on the function of the server and its inter-relationship with other systems, you probably need to manage such a change as a project. As they say, a little bit more of thinking and planning goes a long way.
  • gather requirement from functional groups and management
  • set a date to cut-over and obtain sign-off from stake-holders
  • plan for it (procedures/fall-back plan/check-list/notification/etc.)
  • communicate the planned change and its potential impact to stake-holders and end users
  • dry run if necessary
  • prior to cut-over: for days leading up to the cut-over, shorten TTL for A record for that IP, if it has DNS record and is accessed by DNS name instead of IP alone.
  • prior to cut-over: check to be sure ACL or conduits or fw rules get updated on router/firewalls and systems the server gain access to or from
  • during cut-over: keep team and stake-holders abreast of up-to-date status
  • post cut-over: verify by going through your check-list to determine success
  • post cut-over: enter change log for this event & notify users the cut-over is done
  • post cut-over: alias or real NIC to keep servicing the IP for limited period. (could also just alias the new IP onto the NIC serving the current IP, the cut-over becomes switching who's alias and who's real)
  • post cut-over: added DNAT or reverse proxy rules to catch traffic to the old IP and redirect/log/alert as necessary
  • post cut-over: document this in the knowledge-management system: a scrapbook, a WIKI, a technical writer.

Monday, December 18, 2006

Hobbit Monitor :: how to report multiple temperture probe results

For Dell PowerEdge servers, OMSA can report temperature for multiple probes, notably, "BMC Ambient", "BMC Planaar", "BMC Riser", and one for each physical processor. I initially wrote my own extension script named 'temps' , which reports all probes under one 'status server1.temps green' call. It works for a test server after I did the following on the Hobbit server:
  • defined a RRD graph section in hobbitgraph.cfg for all probes available on that server
  • NCV_temps='*:GAUGE" in hobbitserver.cfg
  • appended temps=ncv to test2rrd line in hobbitserver.cfg
  • restart hobbitd server
When I deployed the same extension code to a different server, the limitation of such an extension became painfully obvious: the graph definition failed when a different server reports more or less probes. Since hobbitgraph.cfg's graph section is keyed to the test name in hobbitgraph.cfg, I can't add custom graph section per server configuration, not to mention it is not scalable!. As for alerting, I tried setting up thresholds on the server. However, it didn't seem to generate any alert even if the threshold is obviously surpassed. wonder if the 'status blah GREEN' reported by the extension script kinda blocked such centralized checking.

After posting the above questions to Hobbit's mailing list and got no answers, I took upon myself to find the answers. Good thing that Hobbit Monitor is licensed using GPLv1. I found the answers in the source code, rrd/do_temperature.c. [[ All hail goes to Open Source & Henrik! ]]
  • the 'temperature' test is built-in. duh...
  • if  'temperature' is used as 'test name' on the client, nothing needs to be changed on the server end.
  • a lump-all status command will do. Format of the data portion is somewhat restrictive. Each probe needs to be in the format of '&green BMCambient 17 62'. 
  • the test can be done locally on the client and the overall $status is reported by 'status server1.temperature $status'.
Wishes:
  • It'd be nice to have such data report format documented elsewhere other than the source code.
  • The current code (4.2RC1-20060712) didn't take input other than integer too well. It confused the hell out of it, in fact, to the extent it lump the whole long after $status as the probe name. Most of problems I experienced was actually the '.' in my data report confused Hobbit.
  • It'd be nice to be able to specify threshold on the server centrally.

Wednesday, December 13, 2006

How to coerce OMSA 5.1 to install & run properly on CentOS 4 (part II)

Not so fast! The same fix doesn't work on CentOS 4.1 running on a Dell PE6850. srvadmin-install.sh somehow determined it needed a newer version of OpenIPMI from its own package, regardless of whether the OS has latest OpenIPMI installed or not. Recall that the same hack worked w/o OpenIPMI installed at all on CentOS 4.4.

# Here is the excerpt from srvadmin-install.sh
Server Administrator requires a newer version of the OpenIPMI driver modules
for the running kernel than are currently installed on the system. The OpenIPMI
driver modules for the running kernel will be upgraded by installing an
OpenIPMI driver RPM.
warning: RPMS/supportRPMS/openipmi-33.13.RHEL4-1dkms.noarch.rpm: V3 DSA signature: NOKEY, key ID 23b66a9d
Preparing... ########################################### [100%]
1:openipmi ########################################### [100%]

Loading kernel module source and prebuilt module binaries (if any)
Installing prebuilt kernel module binaries (if any)

Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.

Your DKMS tree now includes:
openipmi, 33.13.RHEL4, 2.6.9-5.EL, i686: built
openipmi, 33.13.RHEL4, 2.6.9-5.EL, x86_64: built
openipmi, 33.13.RHEL4, 2.6.9-5.ELsmp, i686: built
openipmi, 33.13.RHEL4, 2.6.9-5.ELsmp, x86_64: built
openipmi, 33.13.RHEL4, 2.6.9-5.ELhugemem, i686: built

The OpenIPMI packages is from the CentOS 4.4 release DVD. So, it couldn't be newer !
# rpm -aq|grep -i OpenIPMI
OpenIPMI-libs-1.4.14-1.4E.13
OpenIPMI-1.4.14-1.4E.13

All our production servers don't have kernel source or development kits available. So, dkms approach isn't the one we'd take easily if we have other viable alternatives. So, I modified srvadmin-openipmi.sh to force it not to upgrade IPMI.
# diff srvadmin-openipmi.sh.orig srvadmin-openipmi.sh
1055c1055,1056
< loc_recommended_action="$?
> #LOC_RECOMMENDED_ACTION=$?
> LOC_RECOMMENDED_ACTION=4

This worked for the installation. However, upon start-up the services, the IPMI services failed to start. I ran into problem before with OMSA's own ipmi init script (dsm_sa_ipmi) deleting /dev/ipmi0 while udev never puts it back. So, as a simple hack, I just added a line to add the device at the beginning of the script.
test -e /dev/ipmi0 || mknod -m 0600 /dev/ipmi0 c 253 0

After this, /etc/init.d/dsm_sa_ipmi would start ok, w/o OpenIPMI package installed. However, when it is called from srvadmin-services.sh (I suspect instsvcdrv is the actually caller). It failed each every time, causing omreport could't get any data. For now, I can manually start dsm_sa_ipmi and then start/stop srvadmin-services.sh just fine.

What makes worse (maybe even the cause of this IPMI start-up problem) is that the init sequence numbers assigned to all these init scripts are S50, instead of S00(mptctl), S96(instsvcdrv), and S97 for all the rest. I don't think this will work upon reboot or run level changes. I fixed it manually per chkconfig directives inside the scripts. However, I am curious why chkconfig got confused.

P.S. A more complete tweak would be at beginning of the function in srvadmin-openipmi.sh. The previous tweak on srvadmin-openipmi.sh works only when you have OpenIPMI installed.

# diff srvadmin-openipmi.sh.orig srvadmin-openipmi.sh
973a974,976
> LOC_RECOMMENDED_ACTION=4
> return ${LOC_RECOMMENDED_ACTION}

How to coerce OMSA 5.1 to install & run properly on CentOS 4

To monitor Dell PowerEdge servers running Linux, I downloaded OMSA (Open Manage Server Assistant) 5.1 package for Redhat Enterprise Linux 4 (RHEL4) on a bunch of Dell PowerEdge 6850 servers. The package was listed under 'system management' of the 'drivers & download' section. The actual file name is 'OM_5.1_ManNode_LIN_A00.tar.gz'.

On the PE6850 server, I unpacked the tarball, and attempted to install using the srvadmin-install.sh. It failed silently, with an error code of 2.
# supportscripts/srvadmin-install.sh
# echo $?
2
Examing srvadmin-install.sh closely, I realized that it didn't support CentOS 4. Instead, it supports & detects RHEL4 by its code node 'Nahant'. Instead of mucking the code to support CentOS, I decided to fake RHEL4 by modifying /etc/redhat-release.
# cat /etc/redhat-release
fake RHEL 4 Nahant
It worked.The installation went a-ok and all services started properly. 'omreport storage controllers' now reports various information on various storage controllers.

Thinking the faking was needed only by the installation scripts, I reverted /etc/redhat-release to its original version. To be sure, I restarted OMSA by ' srvadmin-services.sh stop|start'. Well, it didn't pan out that well.

# /usr/bin/srvadmin-services.sh start

Starting mptctl:
Waiting for mptctl driver registration to complete:
[ OK ] Starting Systems Management Device Drivers:
Starting dell_rbu: [ OK ]
Starting ipmi driver: [FAILED]
Starting Systems Management Device Drivers:
Starting dell_rbu: Already started [ OK ]
Starting ipmi driver: [FAILED]
Starting DSM SA Shared Services: [ OK ]

Starting DSM SA Connection Service: [ OK ]

Now it seemed the srvadmin-ipmi package's init script still relies on /etc/redhat-release to tell it which OS it is running on. The server doesn't have OpenIPMI installed. Without any IPMI driver loaded, no report can be run against storage or temps using OMSA.

To have it work for both world (OMSA and CentOS), I cooked up this /etc/redhat-release by appending the RHEL4 code name to the original /etc/redhat-release
# cat /etc/redhat-release.fake
CentOS release 4.4 (Final) Nahant
# /usr/bin/srvadmin-services.sh start
Starting mptctl:
Waiting for mptctl driver registration to complete: [ OK ] Starting Systems Management Device Drivers:
Starting dell_rbu: [ OK ]
Starting ipmi driver: [ OK ]
Starting Systems Management Data Engine:
Starting dsm_sa_datamgr32d: [ OK ]
Starting dsm_sa_eventmgr32d: [ OK ]
Starting DSM SA Shared Services: [ OK ]
Starting DSM SA Connection Service: [ OK ]

This cooked /etc/redhat-release had been verified to work well with 'yum -y update' and OMSA's 'srvadmin-services.sh start'

Wednesday, December 06, 2006

trick to enable non-bridged wireless access on a Netgear Wireless router (WGR614v6)

I bought a Netgear wireless router (WGR614v6) from CompUSA yesterday. It is going to a customer's site for WI-FI blackberries (BB7270). I need a wireless router that can simply
  • obtain its own TCP/IP via DHCP from a network port
  • self-contain its WLAN: NAT/SPI protect all wi-fi devices
I would be happier with a Netgear MR814v3, which we have in the lab and is known to work well with BB7270. All the bugs and glitches we ran into in the past year turned out to be on RIM's end, instead of the "poor" quality perceived by RIM's engineer of consumer-grade wireless access points.

Followed the auto-run wizard from the installation CD to the letter, I connected my own laptop to one of the LAN ports on the unit, with the unit's own Internet port plugged into the wall jacket in my office. Once I did a 'ipconfig /renew' on my laptop, the laptop got TCP/IP settings via DHCP as promised. It is a bit odd to see the DNS server is 192.168.1.1. This means the Netgear unit proxies DNS queries for devices utilizing its DHCP/NAT services. However, two things do not work right:
  • nslookup anything resolves to 192.168.1.1 ?
  • the LED on the front of the unit is not on for the WI-FI? 'Router status' says 'wireless :: off', while the checkbox to turn on 'wireless router radio' was shadowed out!
Searching on Netgear's site, I was relieved/disappointed to find the firmware was up to date. There's a link from WGR614's support page on how to enable the unit as a wireless access point. However, such enabling is to bridge the WLAN to the local LAN. I attempted that to satisfy my curiosity. It requires to use a regular LAN port as the autosense uplink instead of the separate Internet port on the unit. Once I did it, the laptop and a wifi blackberry were bridged to the real Ethernet LAN and got their TCP/IP settings from the real corporate DHCP server instead of from the unit's own DHCP server.

Lo & behold, everything went peachy all of a sudden, after this diversion. The checkbox to turn on wireless router radio option is now available, even if after I moved the cable from regular LAN port to Internet port on the unit. The wireless icon on the unit is blinking green. Power cycle the unit didn't eliminate such capability.

I am a bit at loss why wireless capability was disabled before and how it could be enabled by the steps I took. One thing I should have done at the beginning, is to reset it to factory default, just in case someone has messed it up somehow. The unit has all its seals and should be a new one. Anyhow, I am glad it worked out. However, I can't imagine any non-techie can get this far w/o picking up the phone or returning it to the retailer.

One thing to note is that WPA-PSK worked as advertised, both on the access point and on the BB7270. A lengthy 'mydoaminDS-24random' was used for SSID and the maximum allowed '63RANDOM' as the PSK (Pre-shared key). I couldn't imagine that I can type them in w/o a typo, so I emailed such lengthy secret to the email account currently assigned to my test BB7270. On the BB7270, I copy+paste these lengthy random bits from email to a new WLAN profile creation form under Options/WLAN. It worked great. With older version of BB7270 firmware, copy+paste WEP key fails each every time. I'd assume the bug was fixed by now (from v4.0.1.84 to v.4.0.1.104). On the BES (Blackberry Enterprise Solution) server, a site-specific "IT Policy" got created on the using these WLAN secrets worked great too. However, the SSID somehow took several kicks to get really sucked into the "IT policy". The BBM (Blackberry Manager) didn't complain when SSID didn't take, resulting that a BB7270 provisioned from scratch after nuking didn't carry any WLAN profile at all. Only upon reviewing the IT policy, I was shocked to find SSID field was blank while everything else under the WLAN policy section looked good.

Monday, November 27, 2006

Garmin StreetPilot C320 :: review by Experience

I bought a new Garmin StreetPilot C320 gps right before my trip to Florida over the thanksgiving weekend.
Pros: It worked for most of the part.
Cons:
  • The online registration to unlock the map was extra hassle I didn't expected.
  • Too much other junk in the map causing a 128M SD card hold no more than three states at a time. I was told some other brand has less than 4M a state.
  • Reception is poor. It failed to make its first round of contacts with satellites even if I placed it on the picnic table on the back deck or the front patio stairs. One time on interstate, it failed too, when there's a 16-wheeler nearby. Consider the radio still works, you'd think they should augment/supplement the signal somehow to make it work too. Otherwise, you simply can't drive in a crowded traffic and expect it to guide you.

Here is the other parts when it failed to work or could use some improvements:
  • In St Augustine Beach, FL, I was directed to turn left to Mandrid St for my destination from SR A1A South. It turned out Mandrid street was blocked by a private gate.
  • In Atlanta, GA, I was instructed to turn left in 4 miles off 285 to my house. Nothing was mentioned about a right turn (T-junction) from Ashford-Dunwoody Rd to Mt. Vernon Rd.
  • In Kissimmee, FL, I was directed to a Super Wal-Mart 3.2miles away from the resort we stayed in instead of the one 1.2 miles away. Apparently both had been there for quite few years already.
  • In St. Augustine, FL, we wanted to go to a Thai restaurant. However, the unit complained it couldn't find '4900 SR US 1". By searching 'shopping' on the unit, however, we located a Publix at '1127 SR US 1'. It has been more than one occasions when it claimed no such address can be found even though the whole FL state is loaded.
  • Driving back from Orlando, FL to Atlanta, GA, it said turn in 310 miles when we paid $2.50 at the 2nd toll plaza. I figured $2.50 is cheap for a 300-mile toll road. It turned out it failed to mention the merge from Florida turnpike to I-75 N in 27 miles.

The extra junk turned out to be very handy when we were in Orlando
  • To find a super Wal-Mart to buy a special brand of organic milk for my son, I just selected 'shopping' and spotted the first super Wal-Mart, as the list is sorted by distance from your current location. We left our laptops home on purpose even though places we stayed have free WI-FI. Without the GPS, I guess we'd have to drive around to spot one on the run. We found a CVS and a Publix the same way.
  • We had tickets for Downtown Disney. However, both the tickets and brochures don't list street address. I guess the smart Disney writers assumed everybody know where it is ?! The unit listed it under 'theme parks' as 'Disney Quest'. That solved our problem pretty easily.
All in all, it eliminated quite some headache for my wife and me.

Friday, November 10, 2006

perc 4e/Di on Dell PE6850 saga continues...part C

With the load from the full database dump plus the application load burst we set up last Friday , the problematic server 'syb04' generated a few alerts over the weekend. The alerts complained the stamp didn't show up right after the 'logger' call. We were very excited, thinking we were able to reproduce the problem this quick. The next thing would be just to pick out what to upgrade from a decent list of potential upgrades.

Examining closely the local log as well as the log on the remote syslogd server, however, showed that such 'missing' stamps appeared up right after the complaints of their absence. Most were within the same second, and only one was one second late. Therefore such alerts were identified as false positives.

Needless to say, we were very disappointed. Even worse, this remained the case for the full week. We started to toss around the idea maybe the hiccup was merely a delay and we overacted a little by flipping the switch.

To "add insult to the injury", our constant attention was demanded by a lot of database problems related to application peak load which was coerced to repeat. The problems were:
  • Sybase ASE log device filled up, causing the application peak load come to a sudden halt, until Sybase is restarted with log cleared.
  • Hourly transaction has grown from 20M each to over 1G each. It seemed like some transaction failed to be committed.
  • In turn the transaction dumps filled up the disk.
So far, the server endured seven 24-hour days of load run, which totals 24x7x3= $504 load peaks. A regular day have only 2 peaks, therefore, this equals to 250 days worth of load.

I am betting a small sum of money on the PR (patrol read), whose background scheduling may be surprised by the sudden spike in disk IO caused by the nightly full database backup as well as the daily application peak. To force PR to collide with the load, I wrote a script to check PR status and start one if none is 'In Progress' already, as reported by 'megapr -dispPR -a0'.

BTW, the 'megapr -dispPR -a0' command alone causes the following errors in PERC controller's exportlog. My inquiry on this error got no response from Dell's linux-PowerEdge forum, which is monitored by a few Dell engineers.
11/07 10:25:51: MPT_Rec: INQ Error - Negotiating LD[6] pRfm a07517c0
11/07 10:25:51: MPT_Rec: INQ Error - Negotiating LD[16] pRfm a0743360
11/07 10:25:51: GET: SCSI_chn=ff, rtn status=0

Tuesday, November 07, 2006

debugfs :: handy utility to debug an ext2 or ext3 file system

Today I am learning a useful utility program named 'debugfs'. It is part of e2fsprogs package, an essential package containing axillary programs for ext2 and ext3 file system under Linux.

For a regular file, 'debugfs' can help you find an inode by any data block the file or dir entry is using. Then you can turn around and ask for the name of the inode. This could be handy when some mysterious files causing df and du to disagree whether the filie system is full, or the file system is corrupted or can't mounted to be accessed as usual. More advanced file system features are available too.

# to find what inode is claiming a given data block
# debugfs -R "icheck 12345" /dev/hda1
debugfs 1.35 (28-Feb-2004) Block Inode number 12345 340

# to find the file name given the inode number
# debugfs -R "ncheck 49153" /dev/hda1 debugfs 1.35 (28-Feb-2004) Inode Pathname
49153 /usr/share/locale/ar/LC_MESSAGES/libbonobo-2.0.mo


# Print the location of the inode data structure
# debugfs -R "imap /boot/vmlinuz-2.6.9-42.0.2.EL" /dev/hda1 debugfs 1.35 (28-Feb-2004)
Inode 557516 is part of block group 34
located at block 1114128, offset 0x0580


# to dump the direntry (filespec, per man page)
debugfs -R "dump -p /boot/vmlinuz- 2.6.9-42.0.2.EL /tmp/vmlinuz_dumped" /dev/hda1
# md5sum /boot/vmlinuz-2.6.9-42.0.2.EL /tmp/vmlinuz_dumped
e5c536b539b5ffcaa03b22bd7fcc164a /boot/vmlinuz-2.6.9-42.0.2.EL e5c536b539b5ffcaa03b22bd7fcc164a /tmp/vmlinuz_dumped

# to get the contents of a file, assume the fs can't be mounted and accessed the usually way.
# debugfs -R "cat /etc/redhat-release" /dev/hda1
debugfs 1.35 (28-Feb-2004)
CentOS release 4.4 (Final)

Noteworthy is, for files under /selinux ( a pseudo fs), it can find inode number associated with a data block. However, it couldn't find the file name for the very inode number.
# debugfs -R "ncheck 8" /dev/hda1 debugfs 1.35 (28-Feb-2004)
Inode Pathname
8
# find / -inum 8
/selinux/relabel
# ls -id /selinux/relabel

8 /selinux/relabel
# debugfs -R "icheck 4567" /dev/hda1
debugfs 1.35 (28-Feb-2004) Block Inode number
4567 8

# / is on /dev/hda1
/dev/hda1 8127400 6738524 1306308 84% /

There are a lot of powerful (and dangerous) features such as
  • feature you can set or clear various file system features in the superblock
  • freeb to mark data blocks as unallocated vs. setb
  • freei to free the inode specified
  • clri to clear the contents of the inode
  • chroot to chroot to the directory
  • find_free_block
  • find_free_inode
  • init_filesys to create an ext2 file system
  • kill_file deallocate the file and its blocks. It doesn't remove any direntry to this inode. not ' rm' or 'unlink'.
  • logdump to dump the ext3 journal
  • modify_inode modify the contents of the inode structure
  • ls/mkdir/mknod/rm/rmdir
'debugfs' starts interactively by default, unless you have '-R' to request one-time use only. A session would be like below:
# debugfs
debugfs 1.35 (28-Feb-2004)

debugfs: open /dev/hda1
debugfs: icheck 12345
Block Inode number
12345 340

debugfs: ncheck 340
Inode Pathname
340 /usr/X11R6/lib/xscreensaver/mountain

debugfs: close

debugfs: quit

AUUG November meeting :: Legal Concerns on Blogger & GPLv3

7:26pm last night, I finally made my way into the HP building across I-285 from Perimeter Mall. I couldn't find the front entry with some contruction blocked some part of the road, so I pulled in wherever I can into the only standing-tall building. A few employees passed me from the next lane and were kind enough to roll down their windows to inform me that a badge is required for after-hour access. I buzzed the security guy. Once I told him that I was here for the AUUG meeting, he attempted to buzz me in a few times, to no avail. So, he dispatched someone to come down to get it for me. While I was parking my car, he was standing there holding the door for me. I am really touched.
The presentation is on legal considerations for Bloggers and legal implications of new provisions in GPLv3. It is well done by two lawyers from Manning, Morris, and Somebody, a local law firm and one of the corporate sponsors of AUUG. I knew Linus was not a fan of GPLv3 because of some of the restrictive clauses. It is much clear made the presenter, the motivation behind it is some kinda vendetta against commercialism of some sort by an academic and a pure idealist.

Let me quote below the three most problematic clauses in GPLv3, as discussed in the presentation
  • patent retaliation
  • bundle rights
  • no locked key [ The lawyer's own research ]

Saturday, November 04, 2006

perc 4e/Di on Dell PE6850 saga continues...part B

After searching up & down, I compiled a decent list of potential upgrades and toggles to try out on syb04. None of them is apparently pertinent enough to have you say 'ahh-ha'. I purchased and put into production a new server named syb06, the one killed by oom-killer and cured by kernel-hugemem. With the improved production configuration mix, time is more affordable than last time when syb04 locked up. So, our team of 'experts' decided to reproduce the recent hiccup or the older lockup problem reliably before we attempt a fix this time around.

Hobbit Monitor is running all the servers, so it is rather easy to catch the old lockup problem wherein all checks went to 'purple', as in 'stale', or 'no report received' status. It is a bit tricky to detect when a hiccup happens. If it happens squarely inside the 5-minute interval Hobbit Monitor uses, we'd miss the signal! It seems it is not all that easy to change monitor frequency down to 1 minute for one single client, as nobody has answered my question on the Hobbit mailing list for three days now. After much discussion of alternatives, I come up with a way and verified it works.

With the monitor fine-tuned and focused on syb04, load is added to it first. Count full nightly database backup and daily peak as two load situations, we need have at least 28 peaks to equate to the 14 days leading up to the lockup. The nightly database backup takes only 25 minutes, and is very easy to run it continuously by simply changing cron schedule to every 30 minutes instead of every day. So, we did that. After 20 hours (~= 40 load peaks), nothing happened. Since we don't plan to work over the weekend, it is decided to simulate the daily load peak and let it run continuously. It took some Java code change and it is done. So, we'd have both the application load and the backup load against the server over the weekend.

* fingers-crossed *

Maxtor Personal Storage 3200 320 GB external USB 2.0 drive to stage backups under Linux

Today I bought a Maxtor Personal Storage 3200 320 GB (Model U01H320) from Circuit City. 320G with 8M cache for merely $159. They matched their online price by taking $20 off the $179 in-store price. Amazon.com is selling the same item on behalf of CompUSA for $169.
The drive will be used to stage backups at our co-lo. At work, we've waited too long for a budget to come through for a real NAS or a tape library/magzine/autoloader. It is one of those day-to-day challenges of small businesses which face the same challenges with much more limited resources. The daily full backup set now amounts to 12G, all compressed by gzip, my favorite tool.

From a RHEL 4.4 AS (CentOS 4.4, to be more exact) guest inside VMWare, the drive was detected as USB 1.1 (full speed) instead of USB 2.0. I assume it is a limitation of the VMWare emulation.
usb 1-1: new full speed USB device using address 2
Initializing USB Mass Storage driver...

scsi1 : SCSI emulation for USB Mass Storage devices

Vendor: Maxtor Model: 3200 Rev: 0341

Type: Direct-Access ANSI SCSI revision: 02
USB Mass Storage device found at 2
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB) sda: assuming drive cache: write through
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB) sda: assuming drive cache: write through
sda: sda1
Attached scsi disk sda at scsi1, channel 0, id 0, lun 0

Pretty interesting to see it actually has NTFS as partition type. wonder how it would fly with MacOS out of the box?
Disk /dev/sda: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 38913 312568641 7 HPFS/NTFS
Since I am gonna use it under RHEL 4, I go ahead relabel the partition as 'Linux' and formatted it as EXT3.
/root# mke2fs -L E320G -O sparse_super,dir_index,filetype -T largefile4 -j /dev/sda1
mke2fs 1.35 (28-Feb-2004)
Filesystem label=E320G
OS type: Linux

Block size=4096 (log=2)
Fragment size=4096 (log=2)
76320 inodes, 78142160 blocks
3907108 blocks (5.00%) reserved for the super user

First data block=0

Maximum filesystem blocks=79691776 2385 block groups
32768 blocks per group, 32768 fragments per group
32 inodes per group
Superblock backups stored on blocks:

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 Writing inode tables: done
Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Ahh, I always forgot to reduce the percentage reserved for super user from the default 5% to 1%.
/dev/sda1 312538740 98368 296811940 1% /mnt
/root# tune2fs -m 1 /dev/sda1
tune2fs 1.35 (28-Feb-2004)
Setting reserved blocks percentage to 1 (781421 blocks)

/root# df -kv /mnt

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 312538740 98368 309314688 1% /mnt

Friday, November 03, 2006

Comcast connection problem (Motorolla SF4100) for recent two weeks

I have been having connection problem with Comcast connection problem (Motorola SF4100) for the past two weeks. The speed was not stable at all and may even lost connection. Why the broadband ISP can't provide a robust service just running water or electricity? Is it because
we as customers are not that demanding
  • we fail to scream at them for each every outage or service degradation
  • we fail to find time to talk to our legislators
  • we fail to fail to vote with our feet
  • we fail to penalize them even within the current framework. If everyone can just report the problem, ask for a ticket be opened, calling back to Billing with the ticket number to get a refund! This would help in two fronts
    • the sheer volume of calls/tickets would open some eyes when BI or data warehouse report is in
    • the sheer volume of the refund check would cut into the profit margin
    • the faster and more we complain, the sooner they stop using us as a measuring gauge whether the service is up or not
  • For the least, we should demand a registration be passed so that refund for system-wide outages be automated and to all customer base, instead of the current more-hoopla-for-you scheme: refund is only available for those who went through the trouble reporting the problem, asking for a ticket, calling back to Billing with the ticket number to get a teeny-weeny refund.

Here is the symptoms of the week:
  • power-cycle the cable modem and/or wireless router may or may not help.
  • download speed ranges from 200K to .4KBps to a stall. several times within a hour.
  • Web interface of the cable modem itself shows the following error/warnings. I looked at it when it works properly, it should be all Debug/Informational.
  • When I asked 'router' to 'renew' address, it failed to renew for over a dozens of retries and timed out.
  • Speed test via http://www.speakeasy.net/speedtest/ shows the connection is not stable at all: 600KB/14KB at one point, and 200KB/104KB at another. It really should stay around 700KB/80KB.
061103155029 8-Debug F504.1 Bridge Ethernet Hook. Failed to learn CPE MAC Address.
061103155029 4-Error F507.5 MAC Filters. Add MAC Address can't add entry. Table is full.
061103155019 8-Debug M570.2 Motorola CM certificate present
061103155019 8-Debug M571.7 CM Cert Upgrade Enabled. Initiate after Registration
061103155019 8-Debug I503.0 Cable Modem is OPERATIONAL
061103155019 7-Information B401.0 Authorized
061103155018 8-Debug F502.1 Bridge Forwarding Enabled.
061103155018 8-Debug F502.3 Bridge Learning Enabled.
061103155018 7-Information B0.0 Baseline Privacy
061103155016 7-Information X518.9 Configuration - GGFMMD - Unit Update Enabled by CVC
061103155016 8-Debug I500.1 DOCSIS 1.0 Registration Completed
061103155016 7-Information I500.4 Attempting DOCSIS 1.0 Registration
061103155016 7-Information D509.0 Retrieved TFTP Config File SUCCESS
061103155013 7-Information D507.0 Retrieved Time....... SUCCESS
061103155013 7-Information D511.0 Retrieved DHCP .......... SUCCESS
061103155013 5-Warning D3.0 DHCP WARNING - Non-critical field invalid in response
061103155013 4-Error D530.8 DHCP - Invalid Log Server IP Address.
061103155013 5-Warning D520.2 DHCP Attempt# 6 BkOff: 5s Tot DSC:6 OFF:3 REQ:3 ACK:1
061103155013 3-Critical D1.0 DHCP FAILED - Discover sent, no offer received
061103154959 5-Warning D520.2 DHCP Attempt# 4 BkOff:27s Tot DSC:4 OFF:2 REQ:2 ACK:0
061103154959 3-Critical D1.0 DHCP FAILED - Discover sent, no offer received
061103154932 5-Warning D520.2 DHCP Attempt# 3 BkOff:13s Tot DSC:3 OFF:2 REQ:2 ACK:0
061103154932 3-Critical D2.0 DHCP FAILED - Request sent, No response
061103154927 5-Warning D520.2 DHCP Attempt# 2 BkOff: 4s Tot DSC:2 OFF:1 REQ:1 ACK:0
061103154927 3-Critical D1.0 DHCP FAILED - Discover sent, no offer received
061103154923 5-Warning D520.2 DHCP Attempt# 1 BkOff: 4s Tot DSC:1 OFF:1 REQ:1 ACK:0
061103154923 3-Critical D2.0 DHCP FAILED - Request sent, No response
061103154918 7-Information D0.0 DHCP CM Net Configuration download and Time of Day
061103154918 7-Information T500.0 Acquired Upstream .......... SUCCESS
061103154918 8-Debug T503.1 Acquire US with status OK, powerLevel 19, tempSid 1378
061103154918 8-Debug T505.0 Acquired Upstream with status OK
061103154916 7-Information T501.0 Acquired Downstream (687000000 Hz)........ SUCCESS
061103154916 8-Debug T509.0 Acquired DS with status OK, DS Freq 687000000, US Id 5
061103154906 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154905 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 105000000, US Id 0
061103154905 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154905 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 99000000, US Id 0
061103154905 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154905 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 93000000, US Id 0
061103154905 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154904 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 855000000, US Id 0
061103154904 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154904 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 849000000, US Id 0
061103154904 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154903 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 843000000, US Id 0
061103154903 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154903 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 837000000, US Id 0
061103154903 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154902 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 831000000, US Id 0
061103154902 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154902 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 825000000, US Id 0
061103154902 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154901 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 819000000, US Id 0
061103154901 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154901 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 813000000, US Id 0
061103154901 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154900 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 807000000, US Id 0
061103154900 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154900 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 801000000, US Id 0
061103154900 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154859 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 795000000, US Id 0
061103154859 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154859 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 789000000, US Id 0
061103154859 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154859 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 783000000, US Id 0
061103154859 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154858 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 777000000, US Id 0
061103154858 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154858 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 771000000, US Id 0
061103154858 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154857 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 765000000, US Id 0
061103154857 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154857 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 759000000, US Id 0
061103154857 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154856 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 753000000, US Id 0
061103154856 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154856 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 747000000, US Id 0
061103154856 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154855 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 741000000, US Id 0
061103154855 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154855 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 735000000, US Id 0
061103154855 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154855 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 729000000, US Id 0
061103154855 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154854 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 723000000, US Id 0
061103154854 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154854 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 717000000, US Id 0
061103154854 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154853 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 711000000, US Id 0
061103154853 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154853 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 705000000, US Id 0
061103154853 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154852 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 699000000, US Id 0
061103154852 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154852 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 693000000, US Id 0
061103154852 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154851 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 687000000, US Id 0
061103154851 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154851 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 681000000, US Id 0
061103154851 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154850 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 675000000, US Id 0
061103154850 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154850 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 669000000, US Id 0
061103154850 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154850 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 663000000, US Id 0
061103154850 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154849 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 657000000, US Id 0
061103154849 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154849 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 651000000, US Id 0
061103154849 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154848 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 645000000, US Id 0
061103154848 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154848 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 639000000, US Id 0
061103154848 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154847 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 633000000, US Id 0
061103154847 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154847 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 627000000, US Id 0
061103154847 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154847 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 621000000, US Id 0
061103154847 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154846 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 615000000, US Id 0
061103154846 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154846 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 609000000, US Id 0
061103154846 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154845 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 603000000, US Id 0
061103154845 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154845 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 597000000, US Id 0
061103154845 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154845 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 591000000, US Id 0
061103154845 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154844 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 585000000, US Id 0
061103154844 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154844 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 579000000, US Id 0
061103154844 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154843 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 573000000, US Id 0
061103154843 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154843 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 567000000, US Id 0
061103154843 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154842 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 561000000, US Id 0
061103154842 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154842 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 555000000, US Id 0
061103154842 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154842 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 549000000, US Id 0
061103154842 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154841 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 543000000, US Id 0
061103154841 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154841 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 537000000, US Id 0
061103154841 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154840 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 531000000, US Id 0
061103154840 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154840 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 525000000, US Id 0
061103154840 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154840 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 519000000, US Id 0
061103154840 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154839 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 513000000, US Id 0
061103154839 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154839 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 507000000, US Id 0
061103154839 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154838 8-Debug T509.0 Acquired DS with status NO FEC lock, DS Freq 501000000, US Id 0
061103154838 3-Critical T2.0 SYNC Timing Synchronization failure - Failed to acquire FEC framing
061103154837 7-Information D519.0 DHCP Client shutting down.
061103154837 7-Information H501.2 HFC: Shutting Downstream Down
061103154837 3-Critical I2.0 REG RSP not received
061103154837 1-Emergency I506.0
061103154828 7-Information I500.4 Attempting DOCSIS 1.0 Registration
061103154828 7-Information D509.0 Retrieved TFTP Config File SUCCESS
061103154828 7-Information D507.0 Retrieved Time....... SUCCESS
************ 7-Information D511.0 Retrieved DHCP .......... SUCCESS
************ 5-Warning D3.0 DHCP WARNING - Non-critical field invalid in response
************ 4-Error D530.8 DHCP - Invalid Log Server IP Address.
************ 5-Warning D520.2 DHCP Attempt# 1 BkOff: 5s Tot DSC:1 OFF:1 REQ:1 ACK:1
************ 7-Information D0.0 DHCP CM Net Configuration download and Time of Day
************ 7-Information T500.0 Acquired Upstream .......... SUCCESS