Every now and then you forget what all is on your network. Or you forget the IP address at which a certain device resides. How to find out what's out there? There are a couple of ways to scan the network and see what's out there:
nmap scans the range you select:
nmap -sP 192.168.47.0/24 (the "P" stand for ping)
ping the multicast address of 224.0.0.1 (all hosts)
ping 224.0.0.1
Well behaved devices that understand multicast addresses will answer the ping.
OK, there's nothing earth shattering here, but sometimes I forget syntax and I need an easy place to look it up......
Thursday, October 18, 2007
ssh troubles.. why is everything so hard?
Well, scping my gnucash files from venus to longstreet worked so well (when they were 4 feet apart) that I decided that I would move venus to my home and scp files from there back to longstreet at the office. You know - remote backup is better because of fire, theft, etc. Up until a few days ago, both my linux boxes (venus and longstreet) were at my office. So I bring venus home and plug it up. Eth0, my on-mobo ethernet port, fails to come up. I don't know what to do, so I install another ethernet card that I had laying around in a PCI slot inside venus. Now both eth0 and eth1 fail to come up. Eth0 was working perfectly when I left the office!!! So I take venus to the repair shop. The guy claims to know how to work on linux computers. Well.......
$165 later, he shows me that he can connect to his DSL ISP using venus (on eth1). So I get it home, and plug it up and ......same deal. Both eth0 and eth1 fail to come up. This upsets me terribly. So I unplug my Cisco 871w router from whence venus was supposed to gets its IP address (from dhcp) and plug venus straight into my Comcast cable modem. Now it works. I can surf the Net. So Fedora 6 on venus for some reason doesn't like the dhcp server on my router, but thinks it's OK to talk to the dhcp server at Comcast. Swell.
Now I unplug venus from the cable modem, plug the 871w back into the modem, and plug venus into one of the switchports on the 871w. Now I'm basically back where I started. As part of my "clutching at straws" procedure, I put into venus a DVD that I have that has several live versions of linux. You know...they work without having to be installed on your hard disk. I reboot into Damn Small Linux. Network configuration proceeds without a hitch and now eth1 is working fine!##$#$@%. I'm confused.......
Now I have to enter some stuff into gnucash on venus so I remove the live DVD and boot back into Fedora 6. You guessed it. Now eth1 works and everything is okey dokey.
All this has made me forget what I was origianlly trying to do. Oh yeah...now I remember. I was going to scp files from venus at home back to longstreet at the office. It seems like forever ago that I thought I could actually do that....
So I try it and it works!! (By "works", I mean that I can scp to longstreet over the Internet and NOT have to enter a password each time. I have a shell script that copies the files I want and I will ultimately put that into my crontab. I want to copy the files every night while I sleep; no waking up to enter a password each time!). Another network admin victory. But of course now I want to up the ante. I rented a linux box at The Planet.com. It is my own linux box with Cent 4 OS and a 160 GB hard drive and a public IP address. Very cool. It's probably out in California or some place....So now I want to scp to this linux box too. It works, but still asks for a password each time. I try everything I know about ssh-keygen -t rsa and copying id_rsa.pub to the .ssh directory on the server and putting it into authorized_keys and blah blah blah.....and it still demands that password each time.
I email tech support at The Planet, but they don't do hand holding for weak-unit sys admins. Lots of web searching later I find out that my directory permissions are set too permissive!!! Who knew? Usually you have to fight against firewalls and other devices that are set too restrictive. I didn't know SSH refuses to work if it thinks your system is too much of a pushover. So I change my permissions on /home/tayloe/.ssh/authorized_keys with chmod and try again. It works!
I'm tired of all these tawdry little problems preventing me from getting any real work done... Actually, for sys admins, there is no real work to be done in the ordinary sense. It's all fighting the wretched OS's and network weirdness. And my own cluelessness about permissions.....
chmod 600 /home/tayloe/.ssh/authorized_keys
chmod 700 /home/tayloe/.ssh
At first I did chmod 600 to my .ssh directory too, but I found that I could not even look at the contents of the directory. So as root, I changed it to 700. Now it's time for a chocolate milk shake at Chick Fillet....
$165 later, he shows me that he can connect to his DSL ISP using venus (on eth1). So I get it home, and plug it up and ......same deal. Both eth0 and eth1 fail to come up. This upsets me terribly. So I unplug my Cisco 871w router from whence venus was supposed to gets its IP address (from dhcp) and plug venus straight into my Comcast cable modem. Now it works. I can surf the Net. So Fedora 6 on venus for some reason doesn't like the dhcp server on my router, but thinks it's OK to talk to the dhcp server at Comcast. Swell.
Now I unplug venus from the cable modem, plug the 871w back into the modem, and plug venus into one of the switchports on the 871w. Now I'm basically back where I started. As part of my "clutching at straws" procedure, I put into venus a DVD that I have that has several live versions of linux. You know...they work without having to be installed on your hard disk. I reboot into Damn Small Linux. Network configuration proceeds without a hitch and now eth1 is working fine!##$#$@%. I'm confused.......
Now I have to enter some stuff into gnucash on venus so I remove the live DVD and boot back into Fedora 6. You guessed it. Now eth1 works and everything is okey dokey.
All this has made me forget what I was origianlly trying to do. Oh yeah...now I remember. I was going to scp files from venus at home back to longstreet at the office. It seems like forever ago that I thought I could actually do that....
So I try it and it works!! (By "works", I mean that I can scp to longstreet over the Internet and NOT have to enter a password each time. I have a shell script that copies the files I want and I will ultimately put that into my crontab. I want to copy the files every night while I sleep; no waking up to enter a password each time!). Another network admin victory. But of course now I want to up the ante. I rented a linux box at The Planet.com. It is my own linux box with Cent 4 OS and a 160 GB hard drive and a public IP address. Very cool. It's probably out in California or some place....So now I want to scp to this linux box too. It works, but still asks for a password each time. I try everything I know about ssh-keygen -t rsa and copying id_rsa.pub to the .ssh directory on the server and putting it into authorized_keys and blah blah blah.....and it still demands that password each time.
I email tech support at The Planet, but they don't do hand holding for weak-unit sys admins. Lots of web searching later I find out that my directory permissions are set too permissive!!! Who knew? Usually you have to fight against firewalls and other devices that are set too restrictive. I didn't know SSH refuses to work if it thinks your system is too much of a pushover. So I change my permissions on /home/tayloe/.ssh/authorized_keys with chmod and try again. It works!
I'm tired of all these tawdry little problems preventing me from getting any real work done... Actually, for sys admins, there is no real work to be done in the ordinary sense. It's all fighting the wretched OS's and network weirdness. And my own cluelessness about permissions.....
chmod 600 /home/tayloe/.ssh/authorized_keys
chmod 700 /home/tayloe/.ssh
At first I did chmod 600 to my .ssh directory too, but I found that I could not even look at the contents of the directory. So as root, I changed it to 700. Now it's time for a chocolate milk shake at Chick Fillet....
Thursday, October 4, 2007
Samba, Samba why are you so bad
Today I've been wrestling with Samba again. On venus, one of my linux boxes (which runs Fedora core 6), I went to system-->administration-->server settings--> samba. It clearly shows a folder called /admin to be shared and visible and writable and everything. But....
When I try to do a directory listing of \\venus\admin from my Win XP box it says "Access denied " or "path not found" or some other such hokum. It's always something...
Here's what to do:
First, do ps -e | grep smb to see if samba is even running. Even though /admin appears to be shared according the the Fedora GUI, that is no guarantee that samba is actually running. I supposed I need to make sure samba runs all the time by adding it to the init.d process. That way it'll start automatically after every reboot. But to start it manually just type:
smbd
nmbd
Then make sure your directory is accessible to everybody by changing its permissions to the least restrictive:
chmod 777 /admin/shamrockacct
Finally, make sure you don't have a firewall issue. Iptables is the firewall on venus. To see what iptables is up to, type "iptables -L" at the command prompt. It will show a listing of the rules that iptables is currently enforcing.
In my case, iptables was blocking access from my Windows box even after I had samba started. So for a quick test, I turned iptables completely off and then I was able to see a listing of /admin by typing:
dir \\venus\admin
in a command window on my Window box.
Now I need to start iptables again but this time open whatever ports samba needs. First check the samba checkbox on the system-->administration-->server settings--> samba screen. Then go to the SELinux tab and click on "Modify SELinux Policy". Scroll down to and click on samba. There you will see several checkboxes. I checked the following:
Disable SELinux protection for smbd daemon
Disable SELinux protection for nmbd daemon
Disable SELinux protection for windbind daemon
Now it works! Windows can see and copy files to and from the /venus/admin, but the firewall on venus has opened just those ports (supposedly) that samba needs to operate. SELinux has also loosened up enough to allow samba to work.
When I try to do a directory listing of \\venus\admin from my Win XP box it says "Access denied " or "path not found" or some other such hokum. It's always something...
Here's what to do:
First, do ps -e | grep smb to see if samba is even running. Even though /admin appears to be shared according the the Fedora GUI, that is no guarantee that samba is actually running. I supposed I need to make sure samba runs all the time by adding it to the init.d process. That way it'll start automatically after every reboot. But to start it manually just type:
smbd
nmbd
Then make sure your directory is accessible to everybody by changing its permissions to the least restrictive:
chmod 777 /admin/shamrockacct
Finally, make sure you don't have a firewall issue. Iptables is the firewall on venus. To see what iptables is up to, type "iptables -L" at the command prompt. It will show a listing of the rules that iptables is currently enforcing.
In my case, iptables was blocking access from my Windows box even after I had samba started. So for a quick test, I turned iptables completely off and then I was able to see a listing of /admin by typing:
dir \\venus\admin
in a command window on my Window box.
Now I need to start iptables again but this time open whatever ports samba needs. First check the samba checkbox on the system-->administration-->server settings--> samba screen. Then go to the SELinux tab and click on "Modify SELinux Policy". Scroll down to and click on samba. There you will see several checkboxes. I checked the following:
Disable SELinux protection for smbd daemon
Disable SELinux protection for nmbd daemon
Disable SELinux protection for windbind daemon
Now it works! Windows can see and copy files to and from the /venus/admin, but the firewall on venus has opened just those ports (supposedly) that samba needs to operate. SELinux has also loosened up enough to allow samba to work.
Subscribe to:
Posts (Atom)