This is not an in-depth tutorial on serial consoles, it’s just designed to get you moving faster. I assume you know how to install packages, edit files, etc., or are at least resourceful enough to figure it out. I also assume you’re s-m-r-t enough to try this on a machine you can get to easily, if you mess it up the first time.

On newer machines there are often BIOS serial redirection options, too, which might be useful. Conveniently, check your BIOS! :-)

1. Figure out what speed your terminal server wants to go, as well as the number of data, parity, and stop bits. 9600 is a common default, and the other parameters are often 8, N, and 1. Faster speeds generally mean it’s less annoying to work on them, but it has to be set the same on both sides, and you can go too fast for the cables you have.

You can verify the settings with “/usr/bin/screen /dev/ttyS0″ (as suggested by Greg in the comments), or /usr/bin/minicom (installed as the “minicom” package from Red Hat). If you ever used Telix for DOS you’ll be right at home with minicom. Hit Ctrl-A, then O to get to the configuration menu. Once it is set up properly you should be able to type in Minicom and have it appear on the terminal server, and vice versa. Don’t go on until you can do that.

/dev/ttyS0 is COM1, /dev/ttyS1 is COM2, etc.

From here on out replace 9600, 8N1, and ttyS0 in my examples with the right parameters for your setup.

2. Add the following to /etc/inittab, remembering to substitute the right serial port, and the terminal type you want:

# Serial Console Access
S0:2345:respawn:/sbin/agetty ttyS0 9600 vt100

Have ‘init’ reread inittab by issuing the command “sudo /sbin/telinit q” and you should be able to see something via the terminal server. You might need to hit enter a couple of times to get its attention.

3. If you want to see stuff at boot, edit /etc/grub.conf. Add the following, substituting the proper serial port in “unit”:

serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

(two lines, “serial” and “terminal,” if it wraps)

4. Comment out any line in /etc/grub.conf that starts with “splashimage.” The splash image doesn’t work so well with character-only interfaces.

5. Add “console=ttyS0,9600n8″ to the proper kernel entry in /etc/grub.conf. So your original entry:

title Red Hat Enterprise Linux AS (2.6.9-67.EL)
  root (hd0,0)
  kernel /vmlinuz-2.6.9-67.EL ro root=/dev/sda1 rhgb quiet
  initrd /initrd-2.6.9-67.EL.img

becomes something like:

title Red Hat Enterprise Linux AS (2.6.9-67.EL)
  root (hd0,0)
  kernel /vmlinuz-2.6.9-67.EL ro root=/dev/sda1 rhgb quiet console=ttyS0,9600n8
  initrd /initrd-2.6.9-67.EL.img

(that’s four lines if it’s wrapping)

6. Reboot and check it out. Party like it’s 1989.

If it isn’t working you’ll have to comment out the inittab line and “telinit q” again to free up the serial port, before you try Minicom or screen.

If I have messed something up here let me know in the comments. Thanks!

ShareThis

As always if you have suggestions or corrections just add them as comments, and I’ll update the text here.

This will give you the default /tftpboot directory. I assume that if you need a filesystem there you can handle adding one there on your own. :-) If you want to change the filesystem you can do that in /etc/xinetd.d/tftp, in the server_args field. Don’t forget to reload xinetd after you change it.

1. Install the tftp server software and enable it:

/usr/bin/up2date tftp-server
/sbin/chkconfig tftp on

3. Because it runs via xinetd reload that to pick up the configuration file change:

/sbin/service xinetd reload

4. Edit /etc/sysconfig/iptables-config and edit the IPTABLES_MODULES line to read:

IPTABLES_MODULES="ip_conntrack_tftp"

If you already have something in that line just add the new module with a space as a delimiter, like:

IPTABLES_MODULES="ip_conntrack_ftp ip_conntrack_tftp"

5. Add firewall rules to /etc/sysconfig/iptables. You probably only need UDP, though I always add the TCP rules, too (they’re both listed in /etc/services for port 69):

-A RH-Firewall-1-INPUT -s 10.1.0.0/16 -m tcp -p tcp --dport 69 -j ACCEPT
-A RH-Firewall-1-INPUT -s 10.1.0.0/16 -m udp -p udp --dport 69 -j ACCEPT

(two lines here if it’s wrapping)

6. Restart iptables to pick up the changes from steps 4 and 5:

/sbin/service iptables restart

7. Add the proper lines to /etc/hosts.allow:

in.tftpd: 10.1.

8. Put something in /tftpboot to retrieve with a client, for testing.

9. Use a client from an allowed IP range to test:

$ tftp my.tftp.server.com
tftp> get filename.bin


9. If you get an error check /var/log/secure and /var/log/messages on the server, and start eliminating potential problems one at a time (disable iptables, put ALL in hosts.allow, etc.) until you find the problem.

Have fun!

ShareThis

There isn’t a mode for it in the Linksys setup. There are firmware hacks, but those are another thing completely.

My simple suggestion: instead of using the WAN port for the router’s uplink, just plug the uplink into one of the switch ports on the Linksys. Ta-dum! Instant bridging.

ShareThis

clamd is the scanning daemon, clamav-milter is the milter, and freshclam is the process that updates the virus definitions.

All the commands, in Courier font, should be on one line if they happen to wrap.

1. Install gmp, gmp-devel, sendmail, sendmail-cf, sendmail-devel, zlib, zlib-devel, bzip2, bzip2-devel.
2. Get the sendmail source from sendmail.org. Extract it, go into the libmilter subdirectory. Run "make" and "make install". That will install libmilter into /usr, where sendmail can find it. No need to build the whole sendmail.
3. groupadd clamav
4. useradd -g clamav -s /bin/false -c "Clam AntiVirus" clamav
5. Get the ClamAV source, extract it, build it, install it (three lines, two are make):

   ./configure --prefix=/usr/local/clamav --disable-zlib-vcheck --enable-milter
make
make install

6. Configure /usr/local/clamav/etc/clamd.conf. I changed the following:

   # Example
LogTime: yes
LogSyslog yes
LogFacility LOG_MAIL
PidFile /var/run/clamav/clamd.pid
TemporaryDirectory /tmp
LocalSocket /var/run/clamav/clamd.socket
FixStaleSocket yes
User clamav

   I chose to have it log via syslog to the mail facility. Why? Because I’m lazy and that log gets rotated already. One less thing to have to change & worry about. If you are high-traffic you might want to have logrotate rotate /var/log/maillog daily.

7. Configure /usr/local/clamav/etc/freshclam.conf. I changed the following:

   # Example
LogSyslog yes
LogFacility LOG_MAIL
PidFile /var/run/clamav/freshclam.pid
DatabaseMirror db.us.clamav.net
NotifyClamd /usr/local/clamav/etc/clamd.conf


8. mkdir /var/run/clamav
9. chown clamav.clamav /var/run/clamav/
10. chmod 700 /var/run/clamav
11. Start the base services to make sure they work. You may want to "tail -f /var/log/maillog" while you’re doing this:

    /usr/local/clamav/sbin/clamd
/usr/local/clamav/bin/freshclam -d

12. Configure the milter. Add the following to /etc/mail/sendmail.mc right before the MAILER(smtp)dnl line. It’s two lines, the second beginning with “define”:

    INPUT_MAIL_FILTER(`clamav’, `S=local:/var/run/clamav/clmilter.sock, F=, T=S:4m;R:4m;C:30s;E:10m’)dnl
    define(`confINPUT_MAIL_FILTERS’, `clamav’)
    

13. Make the new sendmail.cf by issuing a "make -C /etc/mail" command.
14. Start the milter process to test it:

    /usr/local/clamav/sbin/clamav-milter -lo /var/run/clamav/clmilter.sock

15. Restart sendmail to make it pick up the configuration changes (service sendmail restart).
16. Send a test email. If everything works make sure you set the services to start at boot, either with the init script that is in the ClamAV contrib directory or just by adding lines to /etc/rc.local.

ShareThis

Dell PowerEdge 1650, 2650, and 1750 servers have an older implementation of IPMI which will let you issue commands locally, but not to these models over the network.

Before you begin:

The Baseboard Management Controller (BMC) is the thing that implements IPMI. It piggybacks on the first built-in NIC so you have to have that attached to the network on the hosts you wish to manage. It uses its own IP address (so you need an extra one).

If you are new to this get a server that is nearby to act as your test machine. Most of the IPMI commands that shut the host down also kill the BMC. If that happens you’ll need to go power the machine on manually. Until you figure out exactly what is okay and what isn’t you’ll be pushing the power button a lot.

You will need a Linux host to send the IPMI commands from. Undoubtedly there are ways to send these commands from other operating systems, but as I am a Linux guy I’ll use that as my example. Feel free to post comments addressing other OSes.

Getting the OS prepared:

1) Install IPMItool and the startup scripts. On Red Hat Enterprise Linux install the OpenIPMI, OpenIPMI-tools, OpenIPMI-libs, and OpenIPMI-devel packages. That will get you everything you need. There are similar packages available for other distributions (SuSE, Ubuntu, CentOS, etc.). You’ll need IPMItool on any machine you want to configure, and any machine you want to send commands from.

2) Enable the IPMI service:

/sbin/chkconfig ipmi on

3) Start the IPMI service, which will load the kernel modules for you:

/sbin/service ipmi start

Configure the BMC for Remote Usage:

1) There are two ways to configure the BMC. You can configure it through the boot-time menu (Ctrl-E), where you can set the management password and IP address information. Or, you can configure it with ipmitool from the OS. Replace my sample IP address, gateway, and netmask with your own:

/usr/bin/ipmitool -I open lan set 1 ipaddr 192.168.40.88
/usr/bin/ipmitool -I open lan set 1 defgw ipaddr 192.168.40.1
/usr/bin/ipmitool -I open lan set 1 netmask 255.255.255.0
/usr/bin/ipmitool -I open lan set 1 access on


2) Secure the BMC, so unauthorized people can’t power cycle your machines. To do this you want to change the default SNMP community, the “null” user password, and the root user password. First, set the SNMP community, either to a random string or something you know:

/usr/bin/ipmitool -I open lan set 1 snmp YOURSNMPCOMMUNITY

Then set the null user password to something random. Replace CRAPRANDOMSTRING with something random and secure:

/usr/bin/ipmitool -I open lan set 1 password CRAPRANDOMSTRING

Last, set the root user password to something you know:

/usr/bin/ipmitool -I open user set password 2 REMEMBERTHIS

Double-check your settings with:

/usr/bin/ipmitool -I open lan print 1

Trying it:

1) You can set an environment variable, IPMI_PASSWORD, with the password you used above. That will save some typing:

export IPMI_PASSWORD="REMEMBERTHIS"

If you use this substitute the “-a” in the following commands with a “-E”.

2) From another machine issue the following command, obviously replacing the IP with the target BMC’s IP:

/usr/bin/ipmitool -I lan -U root -H 192.168.40.88 -a chassis power status

You should get something like:

Chassis Power is on

If you get anything else, or nothing, double-check to make sure the BMC is set right, you entered the right password, and the IP it has is reachable from the machine you’re on. You can double-check your work via the Ctrl-E boot menu, too.

Beyond that, get familiar with:

/usr/bin/ipmitool -I lan -U root -H 192.168.40.88 -a chassis power off

/usr/bin/ipmitool -I lan -U root -H 192.168.40.88 -a chassis power cycle

/usr/bin/ipmitool -I lan -U root -H 192.168.40.88 -a sel list

For me, a “chassis power off” command kills the box. “SEL” is the system event log.

You can issue all of these commands locally, too:

/usr/bin/ipmitool sel list

Hopefully this helps a little. If you find any errors in this please leave me a comment or send me an email. Thanks!

ShareThis