It's been a *really* long time (approximately 7 years) since I've worked on my OSS project, Fd Linux and I'm finally starting to get my lazy ass in check and getting a bit more free time on my week[days,nights,ends] to get my development box set up and work on a new version of Fd Linux.
It's kind been a quirky hiatus from this due to getting deployed to Iraq back in 2003 to 2005 and just getting back into the swing of things, along with getting a house, watching my two girls grow up, and been extremely busy with work. Life kind of gets in the way like that.
Obviously over the years, the PC market has moved away from floppy disks (I honestly think floppy disk drives are *extra* commodities to add to PC's instead of defacto standards) and with solid state media dirt cheap right now and well capable of holding more than 1.44MB's worth of Linux goodness, it's a no brainer to start moving towards USB flash drives.
Right now, I'm working on a side project that will help get the base started for Fd Linux development, which is a home-brew NTP server, running on a PCB-5825 (AMD Geode 300Mhz, 128mb PC-133), booting off of 256MB compact-flash and using a Motorola Oncore UT+ GPS module with PPS as it's time source. There's much more detail to that, but a lot of the rootfs generation groundwork from way back to Fd Linux v1.0.0 will be used to concoct a good setup for this project.
Any rate, stay tuned. I'm pretty excited to get back into my groove.
A good chopping block to expose my ideas, thoughts and most importantly document innovations, breakthroughs, studies and tips associated with anything technology related, along with any other flights off into the depths of humility, despair and egotism all pointed straight at society and all it's infamous devices of good, evil and otherwise.
Friday, October 31, 2008
Saturday, August 02, 2008
PAM max login limits in RedHat Enterprise 5
I found something surprisingly 'odd' with pam_limits.so library when setting up and base lining a few servers the other day at work.
For some reason you can not concurrently use both 'maxsyslogins' and 'maxlogins' at the same time in your /etc/security/limits.conf file to set max authenticated user/group logins per user or system. With my intentions of having a limits of anyone part of, lets say, the 'users' group, could not have more than 3 separate simultaneous logins into the box with a maximum hard limit of 15 total system logins just doesnt seem to work.
So if you're going to try something like this:
...didn't work for me. I have noticed, also, if you have a particular user who is part of several groups (e.g. users and devel groups) and you have limits for both of those groups, once the first group limits is matched, it goes with that rule. But if you have any idea on how to get 'maxlogins' and 'maxsyslogins' to work together, I'd be happy to know.
For some reason you can not concurrently use both 'maxsyslogins' and 'maxlogins' at the same time in your /etc/security/limits.conf file to set max authenticated user/group logins per user or system. With my intentions of having a limits of anyone part of, lets say, the 'users' group, could not have more than 3 separate simultaneous logins into the box with a maximum hard limit of 15 total system logins just doesnt seem to work.
So if you're going to try something like this:
@users hard maxlogins 3
* hard maxsyslogins 15
...didn't work for me. I have noticed, also, if you have a particular user who is part of several groups (e.g. users and devel groups) and you have limits for both of those groups, once the first group limits is matched, it goes with that rule. But if you have any idea on how to get 'maxlogins' and 'maxsyslogins' to work together, I'd be happy to know.
Monday, June 16, 2008
Analyzing and cleaning out Linux/Unix filesystems that fill up
So I have this problem from time to time at work: bastid users or custom processes that either go rogue and start filling up filesystem space at an alarming rate, or crappy code that doesn't clean itself up.
Here's a couple of my favorite commands to help out with that:
`find` Command
If you aren't using `find`, you should. My favorite one-liners for stuff like this:
Find all files in a directory with a size between (for example) 1KB and 10MB that last changed 1 minute(s) ago:
[root@testbox]# find . -type f -size +1024k -and -size -10240k -cmin 1 -exec du -sb '{}' \;
Find all files in a directory with a size at least (for example) 75MB that last changed 1 minute(s) ago:
[root@testbox]# find . -type f -size +76800k -cmin 1 -exec du -sb '{}' \;
Find all files in a directory with a size between (for example) 1MB to 100MB, owned by 'frank' (UID: 501) that last changed 1 minute(s) ago:
[root@testbox]# find . -type f -size +1024k -and -size -102400k -uid 501 -cmin 1 -exec du -sb '{}' \;
...the execution of `du` in my commands will definitely add some overhead, so feel free to leave it off. It's a nice quick human readable presentation if you're in a hurry, but I wouldn't do it if you have a shitload of files that are going match your search.
`lsof` Command
Simply: list open files. This is your friend you can use in tandem with the `find` commands above to narrow down what process(es) are pillaging your filesystem.
What I do is take the output of a particular find command if I see growing files out there but cannot narrow down what process(es) it could be and just simply run:
[root@testbox]# lsof | grep file_name
...where obviously, file_name is some output you got from the `find` command(s).
Those are just some of many tricks to do to track down that type of ridiculousness that happens when things go bad late at night when you're on-call.
Here's a couple of my favorite commands to help out with that:
`find` Command
If you aren't using `find`, you should. My favorite one-liners for stuff like this:
Find all files in a directory with a size between (for example) 1KB and 10MB that last changed 1 minute(s) ago:
[root@testbox]# find . -type f -size +1024k -and -size -10240k -cmin 1 -exec du -sb '{}' \;
Find all files in a directory with a size at least (for example) 75MB that last changed 1 minute(s) ago:
[root@testbox]# find . -type f -size +76800k -cmin 1 -exec du -sb '{}' \;
Find all files in a directory with a size between (for example) 1MB to 100MB, owned by 'frank' (UID: 501) that last changed 1 minute(s) ago:
[root@testbox]# find . -type f -size +1024k -and -size -102400k -uid 501 -cmin 1 -exec du -sb '{}' \;
...the execution of `du` in my commands will definitely add some overhead, so feel free to leave it off. It's a nice quick human readable presentation if you're in a hurry, but I wouldn't do it if you have a shitload of files that are going match your search.
`lsof` Command
Simply: list open files. This is your friend you can use in tandem with the `find` commands above to narrow down what process(es) are pillaging your filesystem.
What I do is take the output of a particular find command if I see growing files out there but cannot narrow down what process(es) it could be and just simply run:
[root@testbox]# lsof | grep file_name
...where obviously, file_name is some output you got from the `find` command(s).
Those are just some of many tricks to do to track down that type of ridiculousness that happens when things go bad late at night when you're on-call.
Tuesday, May 27, 2008
WEP pwn'age... what's next?
After all these years of known vulnerabilities with the technology, I'm still flippin' amazed the percentage of deployed, neighborhood 802.11b/g wireless access points that STILL have WEP encryption enabled. Not saying that WPA-TSIP-PSK is much better (well, if you've got a super, stellar dictionary/phrase list) but... what this oversight gives me is two things:
1) Entertainment for a very short period of time in 20 minute increments...
2) A very big 'network' to explore, play with and hide behind...
I can't give myself all the credit; `aircrack-ng` is a pretty slick tool.
However, just tonight, I've pwn'ed the last WEP-enabled access point on my block... well, all the ones I can reach without using my 20dbi gain omni antenna poking out my basement window ;-) ...now all that is left is burning my braincells watching television and reading slashdot.
1) Entertainment for a very short period of time in 20 minute increments...
2) A very big 'network' to explore, play with and hide behind...
I can't give myself all the credit; `aircrack-ng` is a pretty slick tool.
However, just tonight, I've pwn'ed the last WEP-enabled access point on my block... well, all the ones I can reach without using my 20dbi gain omni antenna poking out my basement window ;-) ...now all that is left is burning my braincells watching television and reading slashdot.
Saturday, May 17, 2008
Cisco VPN client and Fedora Core 8
I recently did a kernel upgrade on my laptop and noticed my Cisco VPN software wasn't working due to needing to recompile the Cisco `vpnclient` code to build the needed modules again.
...and I discovered two things: what I forgot and what I didnt forget.
1) Forgot: how fucking ridiculously broken kernel code is in Fedora's distribution stream. OMFG. Can a person compile anything outside hello_world.c against anything released? (harsh and far from true, but I'm pissed)
2) Didn't Forget: how painful it was to get `vpnclient` going again on my laptop the first time with all the patching and 32/64-bit specific OS crap to take into consideration.
Want the steps? Here you go.
Cisco VPN client packages and patches
I'm running Fedora 8 64-bit on my laptop, and this are the packages that worked for me. Get 'em:
Unpack and patch source
Next, do the following, assuming you've put all this in the same directory or sandbox:
...we'll also need to do a quick hack on the 'Makefile' to make `make` happy.
Compile Cisco VPN source
Ok, now the part you've been waiting for: compile time. Do the following (noting that doing the install requires r00t level access, so I use `sudo` for my needs, do whatever suits yours):
...and then follow the on-screen instructions for installation path, etc. etc. etc.
Testing the Cisco VPN client
Assuming that the compilation of the kernel modules went successfully, now it's time to test out the Cisco VPN client. First, make sure you're actually connected on 'some' network that's going to allow you to get to your VPN. Second, make sure you copy your Cisco VPN profile out in /etc/CiscoSystemsVPNClient/Profiles so you can actually connect to your VPN.
After that, do the following:
...and that's pretty much about it in a quick and dirty way. Hopefully this helps someone. I wasn't going to even attempt to start hacking code to see what was really broken. I had google'd around and noticed that people had it working; the tough part was finding all the correct patches to go with certain code bases (e.g. 64-bit for my 64-bit OS I'm running).
...and I discovered two things: what I forgot and what I didnt forget.
1) Forgot: how fucking ridiculously broken kernel code is in Fedora's distribution stream. OMFG. Can a person compile anything outside hello_world.c against anything released? (harsh and far from true, but I'm pissed)
2) Didn't Forget: how painful it was to get `vpnclient` going again on my laptop the first time with all the patching and 32/64-bit specific OS crap to take into consideration.
Want the steps? Here you go.
Cisco VPN client packages and patches
I'm running Fedora 8 64-bit on my laptop, and this are the packages that worked for me. Get 'em:
- vpnclient-linux-x86_64-4.8.01.0640-k9.tar.gz
- vpnclient-linux-2.6.24-final.diff
- cisco_skbuff_offset.patch
Unpack and patch source
Next, do the following, assuming you've put all this in the same directory or sandbox:
[testbox]$ tar -zxvf vpnclient-x86_64-4.8.01.0640-k9.tar.gz
[testbox]$ mv vpnclient vpnclient-x86_64-4.8.01.0640-k9
[testbox]$ cd vpnclient-x86_64-4.8.01.0640-k9
[testbox]$ patch -p1 < ../vpnclient-linux-2.6.24-final.diff
[testbox]$ patch -p1 < ../cisco_skbuff_offset.patch
...we'll also need to do a quick hack on the 'Makefile' to make `make` happy.
[testbox]$ cp Makefile Makefile.orig
[testbox]$ sed -i -r -e "s/^CFLAGS/EXTRA_CFLAGS/g" Makefile
Compile Cisco VPN source
Ok, now the part you've been waiting for: compile time. Do the following (noting that doing the install requires r00t level access, so I use `sudo` for my needs, do whatever suits yours):
[testbox]$ cd vpnclient-x86_64-4.8.01.0640-k9
[testbox]$ sudo ./vpn_install
...and then follow the on-screen instructions for installation path, etc. etc. etc.
Testing the Cisco VPN client
Assuming that the compilation of the kernel modules went successfully, now it's time to test out the Cisco VPN client. First, make sure you're actually connected on 'some' network that's going to allow you to get to your VPN. Second, make sure you copy your Cisco VPN profile out in /etc/CiscoSystemsVPNClient/Profiles so you can actually connect to your VPN.
After that, do the following:
[testbox]$ sudo /etc/init.d/vpnclient_init start
[testbox]$ sudo vpnclient connect [name_of_profile_you_copied]
...and that's pretty much about it in a quick and dirty way. Hopefully this helps someone. I wasn't going to even attempt to start hacking code to see what was really broken. I had google'd around and noticed that people had it working; the tough part was finding all the correct patches to go with certain code bases (e.g. 64-bit for my 64-bit OS I'm running).
Saturday, April 26, 2008
The re-birth of the subnotebook?
It's funny how things in our culture resurface themselves after decades of silence. From fashion to technology and anywhere in between, it's crazy the amount of odd things that are all the sudden "the thing to have" today.
Odd shit like kids wearing straight leg pants that were cool in the 80's, girls wearing their hair in a pony tail that drags off to the side of their shoulder, and most notably (of course I'm not going to bitch about fashion) the re-birth of the subnotebooks like the Asus Eee and Everex Cloudbook.
...so I ask myself: WTF happened to the Gateway Handbook? I happen to own one of these (and still do) and at the time, I used to run my own homebrew Linux distro on it (Fd Linux), in which I ripped out the 80mb 2.5" hdd and tossed in a IDE micro-controller-to-compact flash, which essentially, despite the shear lack of processing power that the Asus Eee and the Everex Cloudbook boast, isn't much different.
I'd definitely have to say, we are creatures of habit and repetition.
Odd shit like kids wearing straight leg pants that were cool in the 80's, girls wearing their hair in a pony tail that drags off to the side of their shoulder, and most notably (of course I'm not going to bitch about fashion) the re-birth of the subnotebooks like the Asus Eee and Everex Cloudbook.
...so I ask myself: WTF happened to the Gateway Handbook? I happen to own one of these (and still do) and at the time, I used to run my own homebrew Linux distro on it (Fd Linux), in which I ripped out the 80mb 2.5" hdd and tossed in a IDE micro-controller-to-compact flash, which essentially, despite the shear lack of processing power that the Asus Eee and the Everex Cloudbook boast, isn't much different.
I'd definitely have to say, we are creatures of habit and repetition.
Subscribe to:
Posts (Atom)