11 April 2006
chkconfig, et al
Following on from the other day, while cleaning out my tabs this morning I found some added info on disabling services. Some great advice on cleanly disabling things, with the added benefit of not having to remember anything!
1) to save the current state of you services(so that if some dependecies are bork you can still revert back)
chkconfig --list > services.states
1) dump the service names
chkconfig --list | awk '{print $1}' > services.txt
2) del services you want to turn off from services.txt, save it as services.on . you can check what the service does before making a decision with
rpm -qi `rpm -qf /etc/init.d/$SERVICE_NAME`
3) run a script like this
#!/bin/sh
FILENAME='services.on'
MODE='on'
cat $FILENAME |
while read SERVICE_NAME
do
chkconfig --level 345 $SERVICE_NAME $MODE
done
exit
4) repeat 2)3) for services you wanna turn off, just save the config to another file and edit $FILENAME on aforesaid script.
1) to save the current state of you services(so that if some dependecies are bork you can still revert back)
chkconfig --list > services.states
1) dump the service names
chkconfig --list | awk '{print $1}' > services.txt
2) del services you want to turn off from services.txt, save it as services.on . you can check what the service does before making a decision with
rpm -qi `rpm -qf /etc/init.d/$SERVICE_NAME`
3) run a script like this
#!/bin/sh
FILENAME='services.on'
MODE='on'
cat $FILENAME |
while read SERVICE_NAME
do
chkconfig --level 345 $SERVICE_NAME $MODE
done
exit
4) repeat 2)3) for services you wanna turn off, just save the config to another file and edit $FILENAME on aforesaid script.
10 April 2006
Just a question of time
My clock is/was off and ntpd wasn't even running (even though /etc/init.d/ntpd was set +x), so this is how I fixed it: I copied over the server line from my FreeBSD machine. Not very independent with this Linux thing, am I? Apparently the default servers listed in FC4's /etc/ntp.conf are bunk, so listen up.
Seriously though, there are time servers all over the place, so if you don't have a favorite already go ahead a pick one to use. Just take your server (preferably by IP address because there may be a time when DNS is down and you still need to have good time), look for the lines in /etc/ntp.conf that say server and plunk it down in the first position.
It may take a few minutes for it to kick into polling and actually change the time. You can issue a /usr/sbin/ntpd -q to force the synchronization if you're impatient.
Seriously though, there are time servers all over the place, so if you don't have a favorite already go ahead a pick one to use. Just take your server (preferably by IP address because there may be a time when DNS is down and you still need to have good time), look for the lines in /etc/ntp.conf that say server and plunk it down in the first position.
# /sbin/service ntpd start
Starting ntpd: [ OK ]
It may take a few minutes for it to kick into polling and actually change the time. You can issue a /usr/sbin/ntpd -q to force the synchronization if you're impatient.
ntp
Okay, the default servers listed in FC4's /etc/ntp.conf are apparently bunk. My clock is/was off, so this is how I fixed it: I copied over the server line from my FreeBSD machine. Not very independent with this Linux thing, am I? Seriously though, there are time servers all over the place, so if you don't have a favorite already go ahead a pick one to use. Just take your server (by IP, preferably), look for the lines in /etc/ntp.conf that say server and plunk it down in the first position.
It may take a few minutes for it to kick into polling and actually change the time. You can issue a /usr/sbin/ntpd -q to force the synchronization if you're impatient.
# /sbin/service ntpd start
Starting ntpd: [ OK ]
It may take a few minutes for it to kick into polling and actually change the time. You can issue a /usr/sbin/ntpd -q to force the synchronization if you're impatient.
Hostname
I thought I'd be smart and use my intuition, finding some page a week or so ago telling me that to set the hostname all I needed to do was to put the hostname into the textfile /etc/hostname and run hostname -F /etc/hostname. This isn't the first time I've read advice that fixes the immediate problem but doesn't survive a reboot. Linux may not be Windows, but for sure it's necessary to have a machine rise from the dead in a workable state. Combing through man hostname gives me a notion that indeed /etc/hostname should be read at boot by /etc/init.d/boot or /etc/rc.d/rc.inet1, except that neither of those scripts exist on my vanilla FC4 system!
As I read on I make special note not to ignore what seems to be finer points of manpages (always a struggle), I bear down and realize that even though /etc/rc.d/rc.sysinit says
I have now changed this li'l bit to the correct value and sure enough, a reboot confirms that I'm now clean. Well, as clean as can be even if this method doesn't exactly ping my elegance genes with its failure to jibe with the manpages.
As I read on I make special note not to ignore what seems to be finer points of manpages (always a struggle), I bear down and realize that even though /etc/rc.d/rc.sysinit says
# Set the hostname.and /etc/host.conf says order hosts,bind that perhaps there's a middle value there. /etc/hosts doesn't have a hostname, is there anything I'm missing while scanning through man hostname? Why yes! There's a little mention of /etc/sysconfig/network, which in hindsight must not be rewritten by hostname -f [file], but alas:
update_boot_stage RChostname
action $"Setting hostname ${HOSTNAME}: " hostname ${HOSTNAME}
# more /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=localhost.localdomain
I have now changed this li'l bit to the correct value and sure enough, a reboot confirms that I'm now clean. Well, as clean as can be even if this method doesn't exactly ping my elegance genes with its failure to jibe with the manpages.
06 April 2006
Zaps
# cd /etc/init.d
# ll | grep -v x
total 472
-rw-r--r-- 1 root root 1352 May 2 2005 bluetooth
-rw-r--r-- 1 root root 1502 Mar 1 2005 dc_client
-rw-r--r-- 1 root root 1344 Mar 1 2005 dc_server
-rw-r--r-- 1 root root 970 May 2 2005 dund
-rw-r--r-- 1 root root 1525 Mar 2 2005 irda
-rw-r--r-- 1 root root 6248 May 27 2005 isdn
-rw-r--r-- 1 root root 4278 Sep 27 2005 nfs
-rw-r--r-- 1 root root 2860 Sep 27 2005 nfslock
-rw-r--r-- 1 root root 1146 May 2 2005 pand
-rw-r--r-- 1 root root 3978 Mar 2 2005 pcmcia
-rw-r--r-- 1 root root 1877 Apr 11 2005 portmap
-rw-r--r-- 1 root root 2177 Sep 27 2005 rpcgssd
-rw-r--r-- 1 root root 1801 Sep 27 2005 rpcidmapd
-rw-r--r-- 1 root root 2153 Sep 27 2005 rpcsvcgssd
-rw-r--r-- 1 root root 2493 Jan 24 2005 ypbind
A lot of this stuff didn't seem to be listed in ps aux, but I figured I should chmod -x them anyway. By no means an exhaustive list, most of these things are laptop/Bluetooth oriented. Good to know that FC4 will make its best attempt to work with a laptop, if'n ever I use it on one. For now, good bye to these and hello to a less-chatty startup/shutdown.
03 April 2006
Updates
Moving right along.
My goals for this machine right now are threefold: I'd like to move all of my mail, web, and coding stuff off of my other server to this one. In the process I'll be learning me some Linux, which is not much different than FreeBSD so far. Now that I can log in remotely I don't have to futz with moving keyboard cables around with my KVM and I can leave a terminal open all the time, just waiting for me to tackle another step. So now I update.
Sometimes I'll fly by the seat of my pants, especially when learning, so I decided to take the advice of the Fedora Core documentation and update the machine their way:
# yum update
After several screens of downloading and listing and generally informing me of a zillion things that are going to be done, I am asked a question:
Transaction Summary
=============================================================================
Install 10 Package(s)
Update 155 Package(s)
Remove 0 Package(s)
Total download size: 145 M
Is this ok [y/N]:
Of course the first thing I notice is that "No" is the default selection! Additionally, I'm not sure what these 10 packages are that yum says I'm going to be installing. Scrolling up I see a few headings that illustrate things nicely:
=============================================================================
Package Arch Version Repository Size
=============================================================================
Installing:
kernel i686 2.6.16-1.2069_FC4 updates-released 15 M
Updating:
...
Installing for dependencies:
dhcdbd i386 1.9-1.FC4 updates-released 63 k
gphoto2 i386 2.1.6-1.1 updates-released 1.1 M
hicolor-icon-theme noarch 0.8-2 base 24 k
libexif i386 0.6.12-3 base 97 k
libieee1284 i386 0.2.9-2 base 30 k
libsane-hpaio i386 0.9.8-3.2 updates-released 111 k
net-snmp-libs i386 5.2.1.2-fc4.1 updates-released 1.8 M
python-numeric i386 23.7-2 base 679 k
sane-backends i386 1.0.17-0.fc4.1 updates-released 3.0 M
The numbers of items in each of these correspond perfectly to the count above, the kernel being one item and there are nine dependencies to update. There's a lot of garbage in there if you ask me, since I'm not even running any X business yet, but I'll probably get there anyway even if just for fun. This is a basic server at the moment but it doesn't harm anything for a windowing environment to take up a little space. So hicolor-icon-theme can just knock itself out for all I care.
Is this ok [y/N]: Y
Remember, I'm here to make mistakes so that they're documented for the whole of eternity and we find out how little one can know about Linux and still survive!
Downloading Packages:
(1/165): glib2-2.6.6-1.i3 100% |=========================| 568 kB 00:02
(2/165): audit-1.0.14-1.f 100% |=========================| 198 kB 00:00
(3/165): acl-2.2.32-1.FC4 100% |=========================| 64 kB 00:00
...
While I wait for the downloads to move along, I notice that this process is fairly similar to using cvsup on FreeBSD, and in fact is a touch easier. Similarly to apt-get (which I became familiar with during a short stint with Debian Linux a few years ago), cvsup requires one to configure it beforehand. When I started using FreeBSD several years ago I was fortunate enough to know a few people who were willing to handhold me along the first baby steps I took. This boiled down mostly to compiling ports, killing processes, and updating via cvsup. Thing is, when you don't know much about a new operating system - even a Unix(-like) one - tracking down viable repository information can be a little like hunting in the dark. This isn't to say that it's not obvious to those who know, since these things always are, but the process is slightly arcane and tends to use common terms such that search engines don't provide immediate help. So what I'm trying to get at here is that it's nice that yum comes with a basic setup that allowed me to run the updater and it kicked off without any guff. I imagine I'll be fine-tuning it later, finding a closer/faster repository, so on and so forth, but at least I didn't have to go "Uhhhhh...." for three hours until I break down and brave IRC in order to find a kind soul who will offer the correct couple of sentences of help.
(158/165): kernel-2.6.16- 36% |========= | 5.5 MB 00:46 ETA
...
So then I'm dumped unceremoniously back to the command prompt. I'm guessing that there's another command I should run to actually install this stuff. That Fedora site page up there doesn't mention anything about this, unless the cron job that they suggest has some extra voodoo inside of it that gets the junk installed.
As I comb through various pages looking for this mysterious command, I notice that a lot of the yum pages use a lot of space to describe the upgrade process from, say, Fedora Core 4 to FC5. Similar to cvsup on FreeBSD, my goal here is to merely patch the machine up to whatever latest iteration of FC4 exists this evening. So I continue reading and have one of those "I bet the man page would be useful here" moments.
yum update kernel
Yeah, well. So I read the manpage and it's all very englishlike. I type yum install and get a helplist of commandline options. I take a shot in the dark and throw yum install all out there. This generates a little activity through which it becomes apparent that it's processing a cache.
# yum install all
Setting up Install Process
Setting up repositories
http://mirror.averse.net/fedora/linux/core/updates/4/i386/repodata/repomd.xml: [Errno 4] IOError:
Trying other mirror.
updates-released 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
base 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 1.2 MB 00:17
extras : ################################################## 3494/3494
Added 17 new packages, deleted 15 old in 5.70 seconds
Parsing package install arguments
No Match for argument: all
Nothing to do
Ah, but "No match" means "no match", so perhaps an asterisk would help?
# yum install *
Setting up Install Process
Setting up repositories
updates-released 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
base 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for python-dialog to pack into transaction set.
python-dialog-2.7-1.fc4.n 100% |=========================| 3.2 kB 00:00
---> Package python-dialog.noarch 0:2.7-1.fc4 set to be updated
---> Downloading header for fltk-devel to pack into transaction set.
fltk-devel-1.1.6-1.fc4.i3 100% |=========================| 47 kB 00:00
...
Yup! A few minutes later, though, this is all still going on. I think it's installing everything it its catalog! Several minutes pass and it's just a constant stream of packages going by, many more than 165. So...back to the drawing board.
Slowing down, I start from the beginning.
# yum install kernel
Which goes through an identical process, midway asking me if the RedHat GPG key was okay to add to the keyring (slightly fancy). It zips through the rest of the process
...
Installed: kernel.i686 0:2.6.16-1.2069_FC4
Complete!
[root@localhost eric]# reboot
It comes back up just fine, and with the new kernel to boot
$ uname -a
Linux localhost.localdomain 2.6.16-1.2069_FC4 #1 Tue Mar 28 12:19:10 EST 2006 i686 athlon i386 GNU/Linux
Now to figure out how to deal with the rest of those updates...
My goals for this machine right now are threefold: I'd like to move all of my mail, web, and coding stuff off of my other server to this one. In the process I'll be learning me some Linux, which is not much different than FreeBSD so far. Now that I can log in remotely I don't have to futz with moving keyboard cables around with my KVM and I can leave a terminal open all the time, just waiting for me to tackle another step. So now I update.
Sometimes I'll fly by the seat of my pants, especially when learning, so I decided to take the advice of the Fedora Core documentation and update the machine their way:
# yum update
After several screens of downloading and listing and generally informing me of a zillion things that are going to be done, I am asked a question:
Transaction Summary
=============================================================================
Install 10 Package(s)
Update 155 Package(s)
Remove 0 Package(s)
Total download size: 145 M
Is this ok [y/N]:
Of course the first thing I notice is that "No" is the default selection! Additionally, I'm not sure what these 10 packages are that yum says I'm going to be installing. Scrolling up I see a few headings that illustrate things nicely:
=============================================================================
Package Arch Version Repository Size
=============================================================================
Installing:
kernel i686 2.6.16-1.2069_FC4 updates-released 15 M
Updating:
...
Installing for dependencies:
dhcdbd i386 1.9-1.FC4 updates-released 63 k
gphoto2 i386 2.1.6-1.1 updates-released 1.1 M
hicolor-icon-theme noarch 0.8-2 base 24 k
libexif i386 0.6.12-3 base 97 k
libieee1284 i386 0.2.9-2 base 30 k
libsane-hpaio i386 0.9.8-3.2 updates-released 111 k
net-snmp-libs i386 5.2.1.2-fc4.1 updates-released 1.8 M
python-numeric i386 23.7-2 base 679 k
sane-backends i386 1.0.17-0.fc4.1 updates-released 3.0 M
The numbers of items in each of these correspond perfectly to the count above, the kernel being one item and there are nine dependencies to update. There's a lot of garbage in there if you ask me, since I'm not even running any X business yet, but I'll probably get there anyway even if just for fun. This is a basic server at the moment but it doesn't harm anything for a windowing environment to take up a little space. So hicolor-icon-theme can just knock itself out for all I care.
Is this ok [y/N]: Y
Remember, I'm here to make mistakes so that they're documented for the whole of eternity and we find out how little one can know about Linux and still survive!
Downloading Packages:
(1/165): glib2-2.6.6-1.i3 100% |=========================| 568 kB 00:02
(2/165): audit-1.0.14-1.f 100% |=========================| 198 kB 00:00
(3/165): acl-2.2.32-1.FC4 100% |=========================| 64 kB 00:00
...
While I wait for the downloads to move along, I notice that this process is fairly similar to using cvsup on FreeBSD, and in fact is a touch easier. Similarly to apt-get (which I became familiar with during a short stint with Debian Linux a few years ago), cvsup requires one to configure it beforehand. When I started using FreeBSD several years ago I was fortunate enough to know a few people who were willing to handhold me along the first baby steps I took. This boiled down mostly to compiling ports, killing processes, and updating via cvsup. Thing is, when you don't know much about a new operating system - even a Unix(-like) one - tracking down viable repository information can be a little like hunting in the dark. This isn't to say that it's not obvious to those who know, since these things always are, but the process is slightly arcane and tends to use common terms such that search engines don't provide immediate help. So what I'm trying to get at here is that it's nice that yum comes with a basic setup that allowed me to run the updater and it kicked off without any guff. I imagine I'll be fine-tuning it later, finding a closer/faster repository, so on and so forth, but at least I didn't have to go "Uhhhhh...." for three hours until I break down and brave IRC in order to find a kind soul who will offer the correct couple of sentences of help.
(158/165): kernel-2.6.16- 36% |========= | 5.5 MB 00:46 ETA
...
So then I'm dumped unceremoniously back to the command prompt. I'm guessing that there's another command I should run to actually install this stuff. That Fedora site page up there doesn't mention anything about this, unless the cron job that they suggest has some extra voodoo inside of it that gets the junk installed.
As I comb through various pages looking for this mysterious command, I notice that a lot of the yum pages use a lot of space to describe the upgrade process from, say, Fedora Core 4 to FC5. Similar to cvsup on FreeBSD, my goal here is to merely patch the machine up to whatever latest iteration of FC4 exists this evening. So I continue reading and have one of those "I bet the man page would be useful here" moments.
yum update kernel
Yeah, well. So I read the manpage and it's all very englishlike. I type yum install and get a helplist of commandline options. I take a shot in the dark and throw yum install all out there. This generates a little activity through which it becomes apparent that it's processing a cache.
# yum install all
Setting up Install Process
Setting up repositories
http://mirror.averse.net/fedora/linux/core/updates/4/i386/repodata/repomd.xml: [Errno 4] IOError:
Trying other mirror.
updates-released 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
base 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 1.2 MB 00:17
extras : ################################################## 3494/3494
Added 17 new packages, deleted 15 old in 5.70 seconds
Parsing package install arguments
No Match for argument: all
Nothing to do
Ah, but "No match" means "no match", so perhaps an asterisk would help?
# yum install *
Setting up Install Process
Setting up repositories
updates-released 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
base 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for python-dialog to pack into transaction set.
python-dialog-2.7-1.fc4.n 100% |=========================| 3.2 kB 00:00
---> Package python-dialog.noarch 0:2.7-1.fc4 set to be updated
---> Downloading header for fltk-devel to pack into transaction set.
fltk-devel-1.1.6-1.fc4.i3 100% |=========================| 47 kB 00:00
...
Yup! A few minutes later, though, this is all still going on. I think it's installing everything it its catalog! Several minutes pass and it's just a constant stream of packages going by, many more than 165. So...back to the drawing board.
Slowing down, I start from the beginning.
# yum install kernel
Which goes through an identical process, midway asking me if the RedHat GPG key was okay to add to the keyring (slightly fancy). It zips through the rest of the process
...
Installed: kernel.i686 0:2.6.16-1.2069_FC4
Complete!
[root@localhost eric]# reboot
It comes back up just fine, and with the new kernel to boot
$ uname -a
Linux localhost.localdomain 2.6.16-1.2069_FC4 #1 Tue Mar 28 12:19:10 EST 2006 i686 athlon i386 GNU/Linux
Now to figure out how to deal with the rest of those updates...
02 April 2006
On SSH and iptables
It turns out that the default Fedora Core 4 install (or mine, anyway) forbids remote SSH logins. This becomes a problem when the KVM switch becomes more of a hassle than it's worth. For me, it becomes more of a hassle than it's worth when your KVM cause key repeats to stop after about one second. Causing key-repeats to stop after about one second is a problem when you like to play Unreal Tournament 2004 and your character stops moving after about one second because your KVM switch is getting in the way.
After an evening of troubleshooting from the ground up and figuring out that the cable is okay and there isn't a problem with the machine being plugged into a wireless AP, I slept on it. While I slept, I let nmap do it's thing on the box to find some more evidence for this mystery:
While iptables will prevent you from logging in while the default iptables config is running, it apparently doesn't mind if y ou stop the process, login via ssh, then start up iptables again. This makes the next part easier, which is to start up iptables:
...which I'll now do just to be sure.
...and once the machine comes back up it doesn't work
This is the same error that I got before I started all of this, so I'm thinking my iptables rules are incomplete, regardless of what I've read. Looking back at the installed ruleset above, I notice something that could be affecting my happiness here, that my ssh rule comes after the default block of rules from the default config:
After an evening of troubleshooting from the ground up and figuring out that the cable is okay and there isn't a problem with the machine being plugged into a wireless AP, I slept on it. While I slept, I let nmap do it's thing on the box to find some more evidence for this mystery:
# nmap -vvvvv -P0 particleSo..."filtered." Of course. Thankfully I've intended my writing here to be a true ground-up experience. So a little bit of search-and-scan gives me the information I'm looking for: iptables
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-04-03 00:45 PDT
Initiating SYN Stealth Scan against 192.168.20.21 [1663 ports] at 00:45
SYN Stealth Scan Timing: About 8.78% done; ETC: 00:50 (0:05:14 remaining)
Increasing send delay for 192.168.20.21 from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for 192.168.20.21 from 5 to 10 due to max_successful_tryno increase to 5
Increasing send delay for 192.168.20.21 from 10 to 20 due to max_successful_tryno increase to 6
Increasing send delay for 192.168.20.21 from 20 to 40 due to max_successful_tryno increase to 7
Increasing send delay for 192.168.20.21 from 40 to 80 due to max_successful_tryno increase to 8
Increasing send delay for 192.168.20.21 from 80 to 160 due to max_successful_tryno increase to 9
Increasing send delay for 192.168.20.21 from 160 to 320 due to 11 out of 12 dropped probes since last increase.
Increasing send delay for 192.168.20.21 from 320 to 640 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for 192.168.20.21 from 640 to 1000 due to 11 out of 19 dropped probes since last increase.
SYN Stealth Scan Timing: About 20.79% done; ETC: 01:12 (0:21:56 remaining)
The SYN Stealth Scan took 1960.37s to scan 1663 total ports.
Host 192.168.20.21 appears to be up ... good.
All 1663 scanned ports on 192.168.20.21 are: filtered
Nmap finished: 1 IP address (1 host up) scanned in 1960.493 seconds
Raw packets sent: 4762 (190KB) | Rcvd: 1664 (113KB)
#
Flushing firewall rules: [ OK ]So now I can log in remotely.
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
While iptables will prevent you from logging in while the default iptables config is running, it apparently doesn't mind if y ou stop the process, login via ssh, then start up iptables again. This makes the next part easier, which is to start up iptables:
# /etc/init.d/iptables start...add your ssh filter
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
Applying iptables firewall rules: [ OK ]
# /sbin/iptables -A INPUT -p tcp --dport ssh -j ACCEPT...list your iptables config to m ake sure everything is in there (ssh, specifically):
# /sbin/iptables -L...and save your configuration so that this all still works if you reboot:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT ipv6-crypt-- anywhere anywhere
ACCEPT ipv6-auth-- anywhere anywhere
ACCEPT udp -- anywhere
224.0.0.251 udp dpt:5353
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited#
/sbin/iptables-save > /etc/sysconfig/iptables
...which I'll now do just to be sure.
# reboot
Broadcast message from root (pts/0) (Mon Apr 3 13:01:24 2006):
The system is going down for reboot NOW!
...and once the machine comes back up it doesn't work
This is the same error that I got before I started all of this, so I'm thinking my iptables rules are incomplete, regardless of what I've read. Looking back at the installed ruleset above, I notice something that could be affecting my happiness here, that my ssh rule comes after the default block of rules from the default config:
Chain INPUT (policy ACCEPT)Looking at the block of rules denoted by "RH-Firewall-1-INPUT", I notice that the last rule in the block is
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibitedwhich is a catchall rule to block everything not explicitly allowed by previous rules. In the grand-iptables-scheme of things, this will cause my ssh rule never to be seen by the machine. Sure, eventually I imagine that I will be doing away with the default ruleset and make my own, but until then I will see if I can fix this with an edit.
# vi /etc/sysconfig/iptablesI notice here a possible fix:
-A INPUT -j RH-Firewall-1-INPUT...I'll try reversing these two lines
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT...and restarting the daemon.
-A INPUT -j RH-Firewall-1-INPUT
[root@particle sysconfig]# /etc/init.d/iptables stopI disconnect PuTTY and reconnect, then go for the Windows method and actually reboot...and in both cases it works!
[root@particle sysconfig]# /etc/init.d/iptables start
Applying iptables firewall rules: [ OK ]
14 December 2005
Consolation
There's a fundamental disconnect between working in console mode and aesthetics. What I'm trying to say is that there isn't any easy way of finding out what font is best to use in the console because screenshots are more trouble than they're worth (right now, I'll see how I feel in a bit). However, it doesn't matter because after going through the motions of setfont, it becomes apparent with a bit of cursor-up-and-backspace that all of the fonts that Fedora come with are visually the same. I'm sure there's some codepage business behind the scenes, but seeing as I'm just whiling my time away ASCII-style I don't think I'll come up against these subtleties until I'm dealing with the rarefied world of email. We'll see, of course.
That's right, I'm in a console of squishy characters of questionable legibility. So much for aesthetics, but I'm sure there's better fonts out there if I'm willing to install a frame-buffer or something.
Ooops. I seem to have only ran `ls iso*` and by restricting my learning to the little bit of information I found in the first place I looked (after Google), I wound up less-than-informed. It's all the same, since I wasn't satisfied with blocky DOS-era text, I found that there is some built-in graphics support, which went a long way toward solving this seemingly minor problem. I'm sure there's a Jargon File entry for this spiralling into fixing the minorest of problems, but here I am.
A little more experimentation goes a long way toward happiness in this venue. From the framebuffer HOWTO above, one learns of the "vga=" directive in the GRUB boot loader. Copying and pasting the existing section to an area right below it (be sure to comment out "hiddenmenu"), you can experiment all you like with different values of vga=. After first booting with 'vga=788' (800x600) and making sure that nothing blows up, I juice the load line up to the max.
This obviates setfont and gives me a nice field of CLI to play in without killing my eyes. So there you have it, the wisdom of the day: vga=794.
In related news, I was able to mail grub.conf over to the windows machine no problem.
[root@localhost consolefonts]# setfont iso01.08
That's right, I'm in a console of squishy characters of questionable legibility. So much for aesthetics, but I'm sure there's better fonts out there if I'm willing to install a frame-buffer or something.
Ooops. I seem to have only ran `ls iso*` and by restricting my learning to the little bit of information I found in the first place I looked (after Google), I wound up less-than-informed. It's all the same, since I wasn't satisfied with blocky DOS-era text, I found that there is some built-in graphics support, which went a long way toward solving this seemingly minor problem. I'm sure there's a Jargon File entry for this spiralling into fixing the minorest of problems, but here I am.
A little more experimentation goes a long way toward happiness in this venue. From the framebuffer HOWTO above, one learns of the "vga=" directive in the GRUB boot loader. Copying and pasting the existing section to an area right below it (be sure to comment out "hiddenmenu"), you can experiment all you like with different values of vga=. After first booting with 'vga=788' (800x600) and making sure that nothing blows up, I juice the load line up to the max.
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title baba (2.6.11-1.1369_FC4)
root (hd0,0)
kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.11-1.1369_FC4.img
title baba-vga (2.6.11-1.1369_FC4)
root (hd0,0)
kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup00/LogVol00 vga=794
initrd /initrd-2.6.11-1.1369_FC4.img
This obviates setfont and gives me a nice field of CLI to play in without killing my eyes. So there you have it, the wisdom of the day: vga=794.
In related news, I was able to mail grub.conf over to the windows machine no problem.
12 December 2005
apropos
It takes about 12 seconds for me to start wondering about how my life is going to adapt to a 25-line console. Normally I'm 10 seconds from ssh'ing into the box and not having to deal with it. The FreeBSD box in the closet stares at me with my history of su's and ssh password failures from random internet creeps with a glow that only a pixellated DOS font can offer.
Okay, so 'setfont' exists in this *nix as well. Now there's always the dance of the "which font should I use?" This is always succeeded by "which font can I use?" Typing "setfont foo" is fun enough the first time you try it, but if you
...there's like a jillion files in there, or at least it seems like a jillion because they're displayed 25 lines at a time.
The manpage for setfont uses an example with "cybercafe." Well that sounds cool. I'm a hip and Linux-installing guy who, while I've never actually been to a cybercafe, might actually blend into a place like that.
Now this is disgusting. I don't know how this ever made it into the distribution, but my eyes are starting to bleed. Imagine the first draft of the poster for a mediocre sci-fi movie, writ in senior-quality LARGE TYPE EDITION and you're getting an idea of what I wound up with. So, as the world of setfont goes, I have to loop through and check a million fonts until I get tired and just go with whatever has been the least crappy in the previous half-hour. The Peter Principle of screen typography.
Googling is no help. It's all manpages and problems. Someone (hint, hint) needs to come up with a page with images of all of these files. Would it be so hard? Heck, it could be the Rosetta Stone of the anti-GUI crowd. I See A Great Need.
[root@localhost /]# apropos console|grep font
Okay, so 'setfont' exists in this *nix as well. Now there's always the dance of the "which font should I use?" This is always succeeded by "which font can I use?" Typing "setfont foo" is fun enough the first time you try it, but if you
[root@localhost /]# cd /lib/kbd/consolefonts
...there's like a jillion files in there, or at least it seems like a jillion because they're displayed 25 lines at a time.
The manpage for setfont uses an example with "cybercafe." Well that sounds cool. I'm a hip and Linux-installing guy who, while I've never actually been to a cybercafe, might actually blend into a place like that.
[root@localhost consolefonts]# setfont cybercafe
Now this is disgusting. I don't know how this ever made it into the distribution, but my eyes are starting to bleed. Imagine the first draft of the poster for a mediocre sci-fi movie, writ in senior-quality LARGE TYPE EDITION and you're getting an idea of what I wound up with. So, as the world of setfont goes, I have to loop through and check a million fonts until I get tired and just go with whatever has been the least crappy in the previous half-hour. The Peter Principle of screen typography.
Googling is no help. It's all manpages and problems. Someone (hint, hint) needs to come up with a page with images of all of these files. Would it be so hard? Heck, it could be the Rosetta Stone of the anti-GUI crowd. I See A Great Need.
First blush with Fedora 4
So here we are. This blog is ostensibly about my travails with getting to know Fedora 4 Core. Fedora Core 4? I don't know, I'm a Windows guy by trade, and a FreeBSD guy by interest. 10 years or so I've been using the BSD with occasional forays into Slackware and Debian, always to get frustrated by their illogical layout. It's truly a cliche that FreeBSD just works, but here I am. I have some spare time lately so I figure I should get some Linux under my belt rather than muddling through whenever it comes up on the job.
Sitting around last night figuring out what I'm going to do with this spare box, I started to download OpenBSD to get a feel for the guts of BSD and the spirit of Theo. This came to a screeching halt once I realized that I would have to deal in some way with a floppy disk. None of my machines has one of these and my stance on this issue is irreconcilable with Theo's attitude toward the non-free aspects of bootable CDs. So be it.
What's next? Well, Linux is always breathing down my neck. Seeing as how it's everywhere I want to be, including powering the hamster-like doppelganger behind this blog service, perhaps it is time to tackle a piece of the Linux homestead. There, I said it. And I'm doing it. And here I am talking about it.
Thinking for two seconds I figured that Fedora core was the distribution I hear people mumbling about most often. RHEL is in there, too, but I couldn't figure out what ISO's to download by looking at RedHat's site, so I settled on Fedora 4. My lovely ISP, sonic.net, has mirrors of a zillion things, and RedHat's products are one of them. So I commence downloading ISOs. Two hours later I see that all three of them have taken up residence on my hard drive, yet when I parse the FTP site listing, I see that there are four ISOs comprising the Fedora 4 (gotta be F4 from now on, sorry Googlesearchers) distribution. That's okay, I always wanted a set of RedHat 9 CDs (whatever distribution or permutation of RH's offerings that might be). If this F4 thing doesn't work out we just may see what RH9 is all about, but for now it's gonna be a few more hours of sucking down ISOs. This is the part where I go to bed.
Next day, I commence installation. Step one is to drag out the cheapy KVM and hook it up to the box I normally sit at. I throw in CD1 of the F4 set and let it roll out. I play BSD expert and lay out some kind of groovy partitioning scheme that my intuition tells me would work. Luckily for my intuition, the box freezes halfway through and spontaneously reboots. I click the KVM over, see that there's some "Operating System not found" type error and blame the Athlon 1700. That fan looks pretty weak, you know. Three more attempts throughout the afternoon get me to various stages of freezing, once in the middle of kernel copying, another fully at the end of its installation process which mysteriously did not ask for CD2 or CD4 which it has assured me would be necessary for completion. A jumble of reboots all day, basically. Never mind that I was otherwise indisposed with the latest on the Plamegate story and tweaking of my Windows game rig (running your RAM at its rated 333MHz is quite an improvement over 266MHz, by the way).
Round midnight, I remembered that I had an 80-pin IDE cable in the front room, languishing next to a dozing case waiting to be freecycled. Normally this wouldn't be cause for interest, except that I had both the hard drive and the CD-ROM of this machine running off of the same cable. 10 minutes later, the machine had fully installed the server-install of F4 and I was now wondering how to change that dang console font. I have to look it up every time for FreeBSD too, so I guess it'll have to become part of my personal UNIX Rosetta Stone.
Sitting around last night figuring out what I'm going to do with this spare box, I started to download OpenBSD to get a feel for the guts of BSD and the spirit of Theo. This came to a screeching halt once I realized that I would have to deal in some way with a floppy disk. None of my machines has one of these and my stance on this issue is irreconcilable with Theo's attitude toward the non-free aspects of bootable CDs. So be it.
What's next? Well, Linux is always breathing down my neck. Seeing as how it's everywhere I want to be, including powering the hamster-like doppelganger behind this blog service, perhaps it is time to tackle a piece of the Linux homestead. There, I said it. And I'm doing it. And here I am talking about it.
Thinking for two seconds I figured that Fedora core was the distribution I hear people mumbling about most often. RHEL is in there, too, but I couldn't figure out what ISO's to download by looking at RedHat's site, so I settled on Fedora 4. My lovely ISP, sonic.net, has mirrors of a zillion things, and RedHat's products are one of them. So I commence downloading ISOs. Two hours later I see that all three of them have taken up residence on my hard drive, yet when I parse the FTP site listing, I see that there are four ISOs comprising the Fedora 4 (gotta be F4 from now on, sorry Googlesearchers) distribution. That's okay, I always wanted a set of RedHat 9 CDs (whatever distribution or permutation of RH's offerings that might be). If this F4 thing doesn't work out we just may see what RH9 is all about, but for now it's gonna be a few more hours of sucking down ISOs. This is the part where I go to bed.
Next day, I commence installation. Step one is to drag out the cheapy KVM and hook it up to the box I normally sit at. I throw in CD1 of the F4 set and let it roll out. I play BSD expert and lay out some kind of groovy partitioning scheme that my intuition tells me would work. Luckily for my intuition, the box freezes halfway through and spontaneously reboots. I click the KVM over, see that there's some "Operating System not found" type error and blame the Athlon 1700. That fan looks pretty weak, you know. Three more attempts throughout the afternoon get me to various stages of freezing, once in the middle of kernel copying, another fully at the end of its installation process which mysteriously did not ask for CD2 or CD4 which it has assured me would be necessary for completion. A jumble of reboots all day, basically. Never mind that I was otherwise indisposed with the latest on the Plamegate story and tweaking of my Windows game rig (running your RAM at its rated 333MHz is quite an improvement over 266MHz, by the way).
Round midnight, I remembered that I had an 80-pin IDE cable in the front room, languishing next to a dozing case waiting to be freecycled. Normally this wouldn't be cause for interest, except that I had both the hard drive and the CD-ROM of this machine running off of the same cable. 10 minutes later, the machine had fully installed the server-install of F4 and I was now wondering how to change that dang console font. I have to look it up every time for FreeBSD too, so I guess it'll have to become part of my personal UNIX Rosetta Stone.
Beginnings and how to create smoke signals
Step one in using a power supply of unknown provenance is to know what each of the wires does. Or at least the connectors. Most of the time with a standard ATX power supply it's fairly straightforward that some connectors are meant for the motherboard and others are destined for the various hard, floppy and disc drives in the system. Where you need to be careful is when there is a strange pair of wires with a jumper header on the end that looks for sure like it's supposed to be one of the "motherboard" cables. One of the big-block ATX power connectors' friends.
Sure, you RTFM, check and double-check the jumper diagrams to make sure this wire has a claim to its rightful place on the motherboard. "Thermal sensor" you see. This is a nice way of saying that there is sometimes a way for the motherboard to tell the powersupply to cut it out, to take a chill pill because there's enough juice to go around so it needn't be going off whole-hog. Sounds pleasant and simple enough until you try it.
If you've never forced a motherboard to generate smoke before, let me tell you that it's a strange experience. A world of wonder and confusion mixed with fear and stinky air. This stuff is surely toxic by way of one EPA regulation or another. It's at least part of the reason that Americans prefer to send their computer detritus to far-off countries in hopes that someone can get some value out of their garbage. Or at least die trying. Suffice it to say that if you're ingesting this stuff regularly, you might as well take up smoking so that you look cool doing it. It won't make a difference when your lungs are bloody stumps competing with your liver for white blood cells.
Safety tip: be sure you know where the power from the wall enters into the power for the computer system. This makes it easy to yank the life out of the smoke bomb you've just created at 1am on a Sunday night (Monday morning, really). The wisdom of the ages, handed down from generation to generation from back when the original IBM-PC would have taken up a hangar the size of Manhattan if it had been built with vacuum tubes (valves to the Limeys out there) and wire-wrapped coils. I'm sure those guys had a story or two about mismatched voltage and expectations thereof.
Sure, you RTFM, check and double-check the jumper diagrams to make sure this wire has a claim to its rightful place on the motherboard. "Thermal sensor" you see. This is a nice way of saying that there is sometimes a way for the motherboard to tell the powersupply to cut it out, to take a chill pill because there's enough juice to go around so it needn't be going off whole-hog. Sounds pleasant and simple enough until you try it.
If you've never forced a motherboard to generate smoke before, let me tell you that it's a strange experience. A world of wonder and confusion mixed with fear and stinky air. This stuff is surely toxic by way of one EPA regulation or another. It's at least part of the reason that Americans prefer to send their computer detritus to far-off countries in hopes that someone can get some value out of their garbage. Or at least die trying. Suffice it to say that if you're ingesting this stuff regularly, you might as well take up smoking so that you look cool doing it. It won't make a difference when your lungs are bloody stumps competing with your liver for white blood cells.
Safety tip: be sure you know where the power from the wall enters into the power for the computer system. This makes it easy to yank the life out of the smoke bomb you've just created at 1am on a Sunday night (Monday morning, really). The wisdom of the ages, handed down from generation to generation from back when the original IBM-PC would have taken up a hangar the size of Manhattan if it had been built with vacuum tubes (valves to the Limeys out there) and wire-wrapped coils. I'm sure those guys had a story or two about mismatched voltage and expectations thereof.
