in '99 i purchased a desktop computer and monitor from microcenter in a neighboring town (an hour away). within a year the monitor started flickering whenever the computer was booted, but after several minutes (warming up?) the flickering would eventually stop. this behavior could not be reproduced when using the monitor with another computer, nor when using the computer with another monitor.
microcenter's stated repair policy was that data on the hard drives of repaired computers was not warrantied. if they delete your data, then it's your tough luck. i didn't have a way to back-up my data (my old computer's hard drive was too small and it wasn't until later that year that i bought my first CD-RW drive on sale for $100), so i decided to withhold my hard drive as i was able to recreate the problem with a dos boot disk.
so i took a day off from work and drove my monitor and computer to microcenter. i explained everything to the technician and showed him the dos boot disk i used to isolate the problem. i told him i was from out of town and would wait on the computer and he told me to return in an hour. upon returning he told me the problem was a known hardware incompatibility between the video card and the monitor. he said he would need authorization from his manager to replace the video card with a different one and his manager would be in later that morning.
after lunch the manager finally arrives, offers me an inferior video card replacement ("see, they both support 1280x1024, 16 million colors, with 8 MB memory; but disregard the price disparity between your previous video card and this cheap replacement"), and tells me that if i ever bring my computer back to microcenter for repair without a hard drive, they will reject it.
i've never stepped foot within a microcenter to this day and don't ever plan to. (haven't needed to as every computer since then i've built myself with parts from newegg, zipzoomfly, and other online retailers.)
it's java so it runs anywhere. i'm currently running it as a service on a windows 2000 workstation.
the web admin interface is nice.
i'm running the old version (jive messenger) as the newer plugins and expanded database support haven't been reason enough to upgrade and i don't consider security a big enough issue on an intranet. don't let my downplaying of the new plugins discourage you, but instead it should speak highly of how well the basic server fulfills communication needs (instant messaging & chat rooms).
my only other suggestion would be to use psi as the client. it's cross-platform (windows, macosx, linux), coded with qt, so that should easy your it support if there's multiple platforms. of course spark is cross-platform too, being java, but i don't have any experience having found psi sufficient for ~4 years.
i also recommend openvpn. supported on a majority of systems: windows 2k/xp, linux, mac os x, bsds, & solaris. here's the howto.
imho, great example of kernel/user-land separation: tun/tap virtual device driver is the only kernel-side part, the rest is in user-land. no more having freeswan keep the system from cleanly shutting down because of a lost reference to a network device. but there is overhead from context switches between kernel & user, though it's a trade-off i think is worthwhile.
you can do ip or ethernet tunneling, depending how far down the osi model you want to go and how much overhead you are willing/able to process. with a single wireless client in my household, i do ethernet tunneling, as it frees me from having to do any ip routing and configuring a wins server (which i've found problematic with windows 2000 and samba 2.2 on debian stable).
openvpn openvpn can use shared key or tls, just depends on what you want. you can quickly develop a proof of concept with shared keys (prove software installation, network communication, etc work) and then "upgrade" to tls.
openvpn uses openssl for it's encryption/authentication engine. that means that all the scrutiny and improvements openssl receives (security analysis, assembly encoded algorithms, hardware engines, etc) benefits openvpn. i'm interested in doing openvpn on the via epia platform with hardware-assisted openssl serving as wireless xterminals.
encrypting lots of bandwidth means lots of processor cycles, and depending on the speed of your processors and the bandwidth between the two, expect some slow down. this is not particular to openvpn, but any (software) encryption, so choose your hardware accordingly (with lots of benchmarking for your particular use case).
ipsec is a valid option, though i prefer openvpn. ipsec is a standard, and is supported on more platforms than openvpn (especially embedded systems & dedicated hardware), but is firstly cumbersome to configure and secondly compatibility is theoretically possible between all implementation but not guaranteed. i once connected windows 2000 and linux/freeswan using ipsec. nate carlson's howto is invaluable. with linux 2.6 it's even harder to implement ipsec with iptables because neither the in-kernel ipsec implementation nor openswan support virtual interfaces (ipsec[0-9]). supposedly it's "possible" using iptables to tag packets, but i won't consider it "practical" until it's easy enough to be documented in a howto.
you specify the other end's ip address and single udp port. easy to port-forward.
it doesn't encode end-point data in stream, so rat won't get all confused when the other end identifies itself as a non-routable ip address, as with some protocols.
and with multicast, you can do teleconferencing with multiple people.
or somewhat similar, but a full java application (which can be almost instantly launched using webstart): jlgui
i don't know how well they handle ogg streams, as i only use it to play ogg files stored on the same webserver as my personal installation of jlguiapplet.
jlgui not as full featured as the popular winamp or my personal favorite foobar, but for sitting down at a computer other than my workstation and nearly instantly having an mp3/ogg player (without having to install/uninstall anything) nothing beats it.
for viewing stats gleaned from your iptables entries in the syslog: fwanalog
fwanalog essentially rewrites your iptable syslog entries into a format similar to apache log files (can't remember the format name: common log?), and then calls analog to summarize the log (using tables, charts, graphs).
windows has vnc (tightvnc, realvnc, ultravnc) to export the current desktop, but vncserver on unix only works by creating a new desktop (completely unrelated from any current x session).
x0rfbserver (within rfb package) historically has been the solution, but it was plagued with horrible performance. compared to vncserver, x0rfbserver felt as if it was push an entire screenshot once a second.
x11vnc is a replacement for the ill-performing rfb. it performs on par with vncserver, but exporting any x session the user has access to (ie forgot to start x11vnc from the desktop before leaving your desk; no problem: ssh into the computer and execute x11vnc referencing your x session, ie 'DISPLAY=:0.0 x11vnc').
lvm isn't quite there yet. devmapper is (the kernel interface), but lvm2 isn't "recommended for production systems" i believe. i'm running a root partition on lvm, which makes the situation even more precarious.
apm suspend wasn't working until this release. acpi isn't an option for some older machines.
packet writing (with patch) is better supported on 2.4 than 2.6, last i checked a few weeks ago.
the more "popular" features of the kernel are well tested, but the more obscure features are still catching up.
it creates a bootcd from your currently running distribution, and with the version in testing/unstable, a distro within a chroot (from outside the chroot, simply by pointing bootcd to the base of the chroot).
i needed this because i support a debian server running the root fs on lvm, which means to change the size of the root fs, you have to boot to something other than the root fs, like a boot cd. knoppix includes lvm, but it's based off of testing, and the version of the ext2/3 tools on testing are incompatible with those in stable (already burned me once).
so on a debian testing workstation i created a chroot, installed debian within the chroot (as described in the debian woody install document), and pointed bootcd to the chroot.
i installed a bunch of "rescue" apps on the boot cd: parted, fdisk, e2fsck, etc. the live cd is not as smooth knoppix, but then again knoppix has been hand tweaked for a single instance of an installation, where bootcd is generalized for anybody's installation.
now i can effortlessly create a debian testing live cd.
i see the benefits of a web-based firewall builder (especially for a home user where the rules are build from answers to simple, high-level, non-technical questions), but for something more in-depth i use:
i started using the project almost a year ago, and have really been impressed with all the extras that have come on-line since then: user guide, FAQ, web portal, articles, cookbook, etc.
the application:
has a wizard to help jump start building a ruleset
abstracts firewall-specific syntax from firewall design
builds rules for several firewall implementations (iptables, pix, ipfilter, ipf)
for an administrator wanting something more technical than a web-based rule builder, but simpler than learning firewall-specific syntax and implementation details, i recommend firewall builder.
this habeas-spamassassin problem just touches on a bigger problem:
rules are brain-dead.
spam rules work today, but what about tomorrow? what about in a month?
i got several pieces of spam for two days before i said enough and gave the habeas rule a score of zero. all spam email were labeled 99% spam by spamassassin's bayesian rules.
then the next day i had spamassassin label an email from a friend as spam (good thing i check my incoming spam folder!) purely based on rules. spamassassin thought my friend's return address was forged because the return address was juno.com, but he didn't use a juno.com smtp server. unusual? yes. spam? no. bayes declared the email as ham.
i belong to several company mailing lists (compusa, buy.com, circuit city), that could easily trigger spam rules, but my bayes training recognizes them perfectly as ham. and my bayes training identifies every piece of spam as spam after seeing a pattern in three or four emails. static rules can never adapt (except between versions of spamassassin; great, get on the hamster wheel of upgrading).
i'm almost driven to find a way to disable all static rules, leaving only the bayes rules.
bought a lite-on ldw-411s from office depot for $90 ($100 after tax, which was my price point) right before thanksgiving.
i've used it exclusively in linux as that's all i run, except to flash the firmware with the windows executable.
it works great for the data storage i've needed (daily incremental & weekly full tarballs of/etc &/home on a few machines). only used dvd+rw media. the ricoh media included with the drive works well, and only had 1 out of 5 optodisc dvd+rw fail (expected though as optodisc is of inconsistent quality, but cheap). the written media reads fine in my year-old lite-on ltd-163 dvd drive.
- grab the drive - download the latest firmware (FS0F last i looked), - install dvd+rw-tools ("apt-get install dvd+rw-tools", though i rebuilt the sid packages for woody) - install k3b (kde 3 required) or tkdvd (really simple app for my basic needs and a great way to ease into learning the dvd+rw-tools command-line options/arguments) - patch the kernel if you want packet-writing capabilities (also useful for cd-rw, but not rock stable)
here's a list of urls i found during my research during the last two or three weeks.
i tried treemap first, and it was REALLY slow, and consumed tons of memory. i'm testing it under windows, but will also use it for linux. matter of fact, rerunning it on another smaller directory (though still gigabytes large with thousands of files) caused the program to bail (java had exceeded it's stack size or something like that). granted, treemap can also display tree-map formatted "database" files, but i just need it for viewing filesystem usage.
tkdu has all the features i need (ascend/descend into directories, change displayed filesystem depth, etc), a simpler interface, executed in a few seconds (as compared to a few minutes for treeview), and used ~ 80% less memory (20 MB vs 90 MB).
for headless servers, i'm thinking about modifying tkdu to save the filesystem data as pickles, so that it can be displayed on a workstation. this way i could run tkdu nightly from a cron job, and analyze filesystem usage the next morning on my workstation.
of course, i don't know how any of them work with mac packages/bundles? the web page that mentions treeview says that it has problems under *nix-like systems because it doesn't understand symlinks. i have yet to test any of them under linux.
all of the above research was prompted by reading this article, so i don't know that much (yet!).
apt repositories on people.debian.org are not official packages, but unofficially maintained/packaged by official debian maintainers, so these people are familiar with debian policy (and "policy" is an official document, not just a familiar way of doing things).
email the official maintainers and ask if they can recommend a backport repository for their package. or backport the package yourself using apt-src (which you first have to backport by hand from unstable; as easy as wget, dpkg-source -x *.dsc, cd package-version, dpkg-buildpackage -b -us -uc -rfakeroot, cd.., dpkg -i *.deb). i've personally backported airsnort, alsa, dia, esound, ethereal, freeswan, gaim, gnucash, gnupg, grip, jabber, kismet, nessus, psi, spamassasin, tcpdump, wget, wine, xcdroast, and more lesser known packages, so it's possible, but usually you can find someone else who's already backported the package you want.
let debian stable take care of the parts of your system that you just want to work, and use backports to allow you to trade aged stability for new features.
it's kinda simplistic, and won't test the real underlying hardware (because modern drive firmware transparently masks/redirects bad sectors to other good sectors, or so i have heard), but i use badblocks.
last december when i built my most recent machine, i bought the hard drive and a few peripherals last because i was holding out on a really good deal on that stuff. so to test and use my new hardware without a harddrive, i used a knoppix live cd (and saved my config to a floppy, which didn't work perfectly for storing/reapplying my hardware configs). when i finally purchased my harddrive, i used badblocks on the knoppix cd to test my drive. it writes various binary patterns to each sector reading the sector back after each write to verify that the data is maintaining the specific binary pattern. i can't remember how many patterns there are, but assuming there are four different patterns, then each sector gets written to and read four times (once for each pattern), which itself is a pretty good stress test and burn-in.
assuming you are familiar with linux, see the man page for badblocks on the knoppix cd for how to do a destructive read/write test, repeating the test until there are no new bad sectors found. (there's also a read/write non-destructive test, where before each sector is written, it is stored in memory, and written back out after the individual sector is tested, but in my case this was a brand new drive so i had nothing to lose doing a destructive test.)
Re:How'd you boot the clients?
on
ClusterKnoppix
·
· Score: 2, Informative
i haven't messed with clusterknoppix (just knoppix itself), but have looked into net booting a few machines at home to serve as x-terminals (since ltsp packages exist for debian and is included with knoppix).
most newer machines with an on-board nic (my ecs k7s5a) support pxe boot as an option within the bios. but for older machines, net booting requires either a nic that supports net booting (should have an eeprom on the nic), which are not the cheap nics that i've always bought, or with a floppy (which can probably be burned to a cdr to make a bootable cd).
for net boot floppy images see the section "Making Boot Disks for Legacy PCs" in the k12ltsp client set-up instructions. those instructions reference the rom-o-matic website, which supplies dynamically-generated downloadable boot floppies using etherboot.
so for a small (1.44 MB) simple net boot solution for computers that don't support pxe booting, but with a floppy drive (or bootable from a cd), look at the k12ltsp instructions and visit the rom-o-matic website for a net boot floppy.
ps the images might even be on the knoppix cd as net boot floppy images are (sometimes?) distributed with ltsp, but probably not due to space constraints on the knoppix cd.
well, no surprise considering the pdf file was created with "Acrobat Distiller 5.0.5 (Windows)" and titled "Microsoft Word - PlatformServicesWP_031703". call me cheap, but even under windows i use win32 ghostscript to convert ps (generated by adobe's free-beer postscript driver using "print to file") to pdf. sure, using my poor man's method i don't get hyperlinks, but notice that none of the urls in the pdf are hyperlinks either, though i'm sure distiller is capable of such.
sure progeny's head is ian murdock of debian fame, but the doc seems to be authored by robin drake (rdrake), who seems to be a writer/editor (http://hackers.progeny.com/pgi/usermanual.html, http://changelogs.credativ.org/debian/pool/main/x/ xfree86/xfree86_4.1.0-16/changelog), not a hacker, so it's understandable.
but yeah, it does look odd for a "linux" company to be using windows, but i won't go so far as to call it hypocritical.
is it a local isp? if not and regional/national, then they might service me here. (oh please!)
i would even be willing to pay $30/month for 128k-down, 64k-up, (semi-)unmetered access.
i currently pay $15/month for unmetered dial-up, but only get 28k due to lousy phone lines in my apt complex. (i've ran into this problem in every apt complex i've lived in, but then again if i paid $1k/month for a brand new upscale apt i would probably have better [newer] phone lines.)
i do my "apt-get dist-upgrade" downloads every night, so i'm not exasperated by how slow my "narrowband" connection is (except when libc gets updated and 50MB of packages flood testing all at once and cause that night's download to last into the daylight hours). i download isos from work, burn them, and bring them home, so no problem there. about the only thing i use my connection at home for is email and a limited amount of surfing. i do most of my surfing at work. though it's a bit of a pain to have to do everything at work, staying late at the office to purchase something online or research purchases.
purchasing stuff from online shops is a pain over narrowband. browsing different online stores to comparison shop is horribly slow with all the images (buttons, banners, imagemaps) they use. and on the weekends i hate having to get offline to use the telephone, or not be able to get online because i'm expecting a phone call (that may not come on time or even at all).
i don't want blazing speed. i just want to have an always-on connection, something significantly faster than my 28k dial-up, and around $30.
on my three year old laptop, the procmail rule suggested in the spamassassin docs (and pretty much the same as in the parent post) was a little too heavy on the cpu, so i added the nice command.
but that wasn't the only problem. i use fetchmail, which dumps all my fetched mail to exim, which (under debian, i believe) is automatically configured to pipe to procmail. the problem: spamassassin was being started for each email, concurrently. fetching 30 emails started 30 separate instances of spamassassin which quickly exceeded/proc/sys/fs/file-max. so i bumped up file-max. then i started running out of memory. (this is why spamd/spamc was created: to eliminate the overhead of multiple perl/spamassassin instances by having a single daemon do the processing.)
finally i analyzed the problem and realized that i needed to serialize the process (for the sake of my laptop) as nothing yet had worked. i applied a lock file to the procmail rule (though i'm not sure specifying the lock file name is necessary but i didn't want to experiment and see if procmail could determine a name or not) and everything is okay except that processing email with spamassassin delays mail delivery (which usually isn't noticed when the mail is processed as it arrives except that i execute fetchmail manually after dialing into my isp so i know when fetchmail retrieves it and when it's finally available to be read a minute or two later), and even more so now that everything is serialized (though with a single spamassassin instance maxing out my cpu, i'm not sure multiple instances was that much faster).
oh, and as the updated spamassassin documentation says, you'll want to add the file size check, or that'll make you run out of memory too.
hope that helps somebody keep from having the same rocky initial experience as me.
this is great to see as this has been touted (by others and myself) to be where open source makes the most sense to a company: non-business-core computer software.
the weather channel's primary business is grabbing eyeballs (to sell itself to cable companies or to sell air-time through commercials during its segments) and it does that through weather forecasting.
video drivers are not the mainstay of their business, but definitely help them in their business. the weather channel doesn't care about selling video drivers. that's not their business. they just need video drivers. and they can pay someone else to create those video drivers and then give the source code away without "selling the farm": giving away a business secret to a competitor.
this would be the same as a music production company paying someone to produce open source drivers for a sound card. the company gets drivers, free support from the community, and yet doesn't give away its secrets or the upper hand to competitors. it's a win-win situation for the company and the community.
this is how i expect to see open source prevail in the future: companies paying for open source development that aids their business (but is not their sole business), and the action being justified by knowing that the open source community (that has an interest in the developed software) will support (to some degree) the software.
in the weather channel's case, this made perfect sense.
that's exactly what i do. my workstation at home has uw-imapd installed, and i can access my mail from any computer on my home network from any client that supports imap from any os.
the reason for this setup is because i wanted the flexibility to use any client and keep the interface to my mailboxes standardized (where some mail clients insist on their own mailbox format).
i was a eudora user for a LONG time (since windows 3.1 when you could carry eudora, your configuration, and recent email on a single 3.5" floppy) and that was the only thing keeping me chained to windows (dual-boot). i used eudora under wine, but it never looked the same and there was a different glitch with each new wine release. i wanted a linux native client.
first i researched a portable client for both linux and windows, but i didn't like any of the native clients and i'm not too crazy about what's required to set up a java runtime environment under linux and/or windows.
then i figured i would use the same imap server under both windows and linux, freeing me to use any client i wanted, and found a cygwin port of imapd, but the performance was horrid.
so finally i resolved to only use linux for my email platform (as i'm there 99% of the time), use imapd, and some undecided mail client. it was nice being able to try out different clients, and not having to convert/import my mail from one format/client to another, etc.
i've finally settled down with procmail, fetchmail, a script to manually kick-off fetchmail and also run mailstat, evolution (integrates with my handspring visor), and sometimes mutt if i just want to quickly read or lookup a message. if i get sent something for my wife, then i just log her into my imap account and transfer the email to her client (eudora) on her machine. this set-up works great.
Slashdot Mirror
in '99 i purchased a desktop computer and monitor from microcenter in a neighboring town (an hour away). within a year the monitor started flickering whenever the computer was booted, but after several minutes (warming up?) the flickering would eventually stop. this behavior could not be reproduced when using the monitor with another computer, nor when using the computer with another monitor.
microcenter's stated repair policy was that data on the hard drives of repaired computers was not warrantied. if they delete your data, then it's your tough luck. i didn't have a way to back-up my data (my old computer's hard drive was too small and it wasn't until later that year that i bought my first CD-RW drive on sale for $100), so i decided to withhold my hard drive as i was able to recreate the problem with a dos boot disk.
so i took a day off from work and drove my monitor and computer to microcenter. i explained everything to the technician and showed him the dos boot disk i used to isolate the problem. i told him i was from out of town and would wait on the computer and he told me to return in an hour. upon returning he told me the problem was a known hardware incompatibility between the video card and the monitor. he said he would need authorization from his manager to replace the video card with a different one and his manager would be in later that morning.
after lunch the manager finally arrives, offers me an inferior video card replacement ("see, they both support 1280x1024, 16 million colors, with 8 MB memory; but disregard the price disparity between your previous video card and this cheap replacement"), and tells me that if i ever bring my computer back to microcenter for repair without a hard drive, they will reject it.
i've never stepped foot within a microcenter to this day and don't ever plan to. (haven't needed to as every computer since then i've built myself with parts from newegg, zipzoomfly, and other online retailers.)
let me second jive software's wildfire jabber server.
it's java so it runs anywhere. i'm currently running it as a service on a windows 2000 workstation.
the web admin interface is nice.
i'm running the old version (jive messenger) as the newer plugins and expanded database support haven't been reason enough to upgrade and i don't consider security a big enough issue on an intranet. don't let my downplaying of the new plugins discourage you, but instead it should speak highly of how well the basic server fulfills communication needs (instant messaging & chat rooms).
my only other suggestion would be to use psi as the client. it's cross-platform (windows, macosx, linux), coded with qt, so that should easy your it support if there's multiple platforms. of course spark is cross-platform too, being java, but i don't have any experience having found psi sufficient for ~4 years.
there's no licensing restriction on visual studio express.
taken from here.
i also recommend openvpn. supported on a majority of systems: windows 2k/xp, linux, mac os x, bsds, & solaris. here's the howto.
imho, great example of kernel/user-land separation: tun/tap virtual device driver is the only kernel-side part, the rest is in user-land. no more having freeswan keep the system from cleanly shutting down because of a lost reference to a network device. but there is overhead from context switches between kernel & user, though it's a trade-off i think is worthwhile.
you can do ip or ethernet tunneling, depending how far down the osi model you want to go and how much overhead you are willing/able to process. with a single wireless client in my household, i do ethernet tunneling, as it frees me from having to do any ip routing and configuring a wins server (which i've found problematic with windows 2000 and samba 2.2 on debian stable).
openvpn openvpn can use shared key or tls, just depends on what you want. you can quickly develop a proof of concept with shared keys (prove software installation, network communication, etc work) and then "upgrade" to tls.
openvpn uses openssl for it's encryption/authentication engine. that means that all the scrutiny and improvements openssl receives (security analysis, assembly encoded algorithms, hardware engines, etc) benefits openvpn. i'm interested in doing openvpn on the via epia platform with hardware-assisted openssl serving as wireless xterminals.
encrypting lots of bandwidth means lots of processor cycles, and depending on the speed of your processors and the bandwidth between the two, expect some slow down. this is not particular to openvpn, but any (software) encryption, so choose your hardware accordingly (with lots of benchmarking for your particular use case).
ipsec is a valid option, though i prefer openvpn. ipsec is a standard, and is supported on more platforms than openvpn (especially embedded systems & dedicated hardware), but is firstly cumbersome to configure and secondly compatibility is theoretically possible between all implementation but not guaranteed. i once connected windows 2000 and linux/freeswan using ipsec. nate carlson's howto is invaluable. with linux 2.6 it's even harder to implement ipsec with iptables because neither the in-kernel ipsec implementation nor openswan support virtual interfaces (ipsec[0-9]). supposedly it's "possible" using iptables to tag packets, but i won't consider it "practical" until it's easy enough to be documented in a howto.
rat
you specify the other end's ip address and single udp port. easy to port-forward.
it doesn't encode end-point data in stream, so rat won't get all confused when the other end identifies itself as a non-routable ip address, as with some protocols.
and with multicast, you can do teleconferencing with multiple people.
in the vein of java applets try:
jlguiapplet
or somewhat similar, but a full java application (which can be almost instantly launched using webstart):
jlgui
i don't know how well they handle ogg streams, as i only use it to play ogg files stored on the same webserver as my personal installation of jlguiapplet.
jlgui not as full featured as the popular winamp or my personal favorite foobar, but for sitting down at a computer other than my workstation and nearly instantly having an mp3/ogg player (without having to install/uninstall anything) nothing beats it.
for viewing stats gleaned from your iptables entries in the syslog: fwanalog
fwanalog essentially rewrites your iptable syslog entries into a format similar to apache log files (can't remember the format name: common log?), and then calls analog to summarize the log (using tables, charts, graphs).
windows has vnc (tightvnc, realvnc, ultravnc) to export the current desktop, but vncserver on unix only works by creating a new desktop (completely unrelated from any current x session).
x0rfbserver (within rfb package) historically has been the solution, but it was plagued with horrible performance. compared to vncserver, x0rfbserver felt as if it was push an entire screenshot once a second.
x11vnc is a replacement for the ill-performing rfb. it performs on par with vncserver, but exporting any x session the user has access to (ie forgot to start x11vnc from the desktop before leaving your desk; no problem: ssh into the computer and execute x11vnc referencing your x session, ie 'DISPLAY=:0.0 x11vnc').
x11vnc
package: http://packages.debian.org/x11vnc
homepage: http://libvncserver.sourceforge.net/
linux-wlan list
swish++
swish-e
what i really liked about altavista personal search was the advanced search syntax (and, or, not, etc).
not being argumentative, but for other's sake:
lvm isn't quite there yet. devmapper is (the kernel interface), but lvm2 isn't "recommended for production systems" i believe. i'm running a root partition on lvm, which makes the situation even more precarious.
apm suspend wasn't working until this release. acpi isn't an option for some older machines.
packet writing (with patch) is better supported on 2.4 than 2.6, last i checked a few weeks ago.
the more "popular" features of the kernel are well tested, but the more obscure features are still catching up.
if running debian...
apt-get install bootcd
it creates a bootcd from your currently running distribution, and with the version in testing/unstable, a distro within a chroot (from outside the chroot, simply by pointing bootcd to the base of the chroot).
i needed this because i support a debian server running the root fs on lvm, which means to change the size of the root fs, you have to boot to something other than the root fs, like a boot cd. knoppix includes lvm, but it's based off of testing, and the version of the ext2/3 tools on testing are incompatible with those in stable (already burned me once).
so on a debian testing workstation i created a chroot, installed debian within the chroot (as described in the debian woody install document), and pointed bootcd to the chroot.
i installed a bunch of "rescue" apps on the boot cd: parted, fdisk, e2fsck, etc. the live cd is not as smooth knoppix, but then again knoppix has been hand tweaked for a single instance of an installation, where bootcd is generalized for anybody's installation.
now i can effortlessly create a debian testing live cd.
firewall builder
i started using the project almost a year ago, and have really been impressed with all the extras that have come on-line since then: user guide, FAQ, web portal, articles, cookbook, etc.
the application:
has a wizard to help jump start building a ruleset
abstracts firewall-specific syntax from firewall design
builds rules for several firewall implementations (iptables, pix, ipfilter, ipf)
for an administrator wanting something more technical than a web-based rule builder, but simpler than learning firewall-specific syntax and implementation details, i recommend firewall builder.
a satisfied user
this habeas-spamassassin problem just touches on a bigger problem:
rules are brain-dead.
spam rules work today, but what about tomorrow? what about in a month?
i got several pieces of spam for two days before i said enough and gave the habeas rule a score of zero. all spam email were labeled 99% spam by spamassassin's bayesian rules.
then the next day i had spamassassin label an email from a friend as spam (good thing i check my incoming spam folder!) purely based on rules. spamassassin thought my friend's return address was forged because the return address was juno.com, but he didn't use a juno.com smtp server. unusual? yes. spam? no. bayes declared the email as ham.
i belong to several company mailing lists (compusa, buy.com, circuit city), that could easily trigger spam rules, but my bayes training recognizes them perfectly as ham. and my bayes training identifies every piece of spam as spam after seeing a pattern in three or four emails. static rules can never adapt (except between versions of spamassassin; great, get on the hamster wheel of upgrading).
i'm almost driven to find a way to disable all static rules, leaving only the bayes rules.
rules are dead! long live bayes!
bought a lite-on ldw-411s from office depot for $90 ($100 after tax, which was my price point) right before thanksgiving.
/etc & /home on a few machines). only used dvd+rw media. the ricoh media included with the drive works well, and only had 1 out of 5 optodisc dvd+rw fail (expected though as optodisc is of inconsistent quality, but cheap). the written media reads fine in my year-old lite-on ltd-163 dvd drive.
/
e x.pl/news2
i've used it exclusively in linux as that's all i run, except to flash the firmware with the windows executable.
it works great for the data storage i've needed (daily incremental & weekly full tarballs of
- grab the drive
- download the latest firmware (FS0F last i looked),
- install dvd+rw-tools ("apt-get install dvd+rw-tools", though i rebuilt the sid packages for woody)
- install k3b (kde 3 required) or tkdvd (really simple app for my basic needs and a great way to ease into learning the dvd+rw-tools command-line options/arguments)
- patch the kernel if you want packet-writing capabilities (also useful for cd-rw, but not rock stable)
here's a list of urls i found during my research during the last two or three weeks.
authoritative source
http://fy.chalmers.se/~appro/linux/DVD+RW
packet writing reference
http://www.pond-weed.com/dvd/
k3b v0.10 & growisofs
http://k3b.sourceforge.net/cgi-bin/ind
tkdvd
http://www.nongnu.org/tkdvd/
enjoy!
1. tkdu
http://unpythonic.dhs.org/~jepler/tkdu/
tkinter (= python + tk)
gpl
2. treemap
http://www.cs.umd.edu/hcil/treemap
java
mentioned here
can't charge for redistribution
3. xdiskusage
http://xdiskusage.sourceforge.net/
gpl
*nix only
i tried treemap first, and it was REALLY slow, and consumed tons of memory. i'm testing it under windows, but will also use it for linux. matter of fact, rerunning it on another smaller directory (though still gigabytes large with thousands of files) caused the program to bail (java had exceeded it's stack size or something like that). granted, treemap can also display tree-map formatted "database" files, but i just need it for viewing filesystem usage.
tkdu has all the features i need (ascend/descend into directories, change displayed filesystem depth, etc), a simpler interface, executed in a few seconds (as compared to a few minutes for treeview), and used ~ 80% less memory (20 MB vs 90 MB).
for headless servers, i'm thinking about modifying tkdu to save the filesystem data as pickles, so that it can be displayed on a workstation. this way i could run tkdu nightly from a cron job, and analyze filesystem usage the next morning on my workstation.
of course, i don't know how any of them work with mac packages/bundles? the web page that mentions treeview says that it has problems under *nix-like systems because it doesn't understand symlinks. i have yet to test any of them under linux.
all of the above research was prompted by reading this article, so i don't know that much (yet!).
i highly recommend going with stable (currently woody) and using backports to stay up-to-date on packages that you need/want.
8 6/ ./8 6/ ./
.., dpkg -i *.deb). i've personally backported airsnort, alsa, dia, esound, ethereal, freeswan, gaim, gnucash, gnupg, grip, jabber, kismet, nessus, psi, spamassasin, tcpdump, wget, wine, xcdroast, and more lesser known packages, so it's possible, but usually you can find someone else who's already backported the package you want.
# snort (from the debian maintainer himself)
deb http://people.debian.org/~ssmeenk/snort-stable-i3
deb-src http://people.debian.org/~ssmeenk/snort-stable-i3
# kde
deb http://download.kde.org/stable/3.1.2/Debian stable main
deb-src http://download.kde.org/stable/3.1.2/Debian stable main
for spamassassin, take your pick.
for nessus, look here again.
for other packages, search here.
apt repositories on people.debian.org are not official packages, but unofficially maintained/packaged by official debian maintainers, so these people are familiar with debian policy (and "policy" is an official document, not just a familiar way of doing things).
email the official maintainers and ask if they can recommend a backport repository for their package. or backport the package yourself using apt-src (which you first have to backport by hand from unstable; as easy as wget, dpkg-source -x *.dsc, cd package-version, dpkg-buildpackage -b -us -uc -rfakeroot, cd
let debian stable take care of the parts of your system that you just want to work, and use backports to allow you to trade aged stability for new features.
deb http://download.kde.org/stable/3.1.2/Debian stable main
deb-src http://download.kde.org/stable/3.1.2/Debian stable main
it's kinda simplistic, and won't test the real underlying hardware (because modern drive firmware transparently masks/redirects bad sectors to other good sectors, or so i have heard), but i use badblocks.
last december when i built my most recent machine, i bought the hard drive and a few peripherals last because i was holding out on a really good deal on that stuff. so to test and use my new hardware without a harddrive, i used a knoppix live cd (and saved my config to a floppy, which didn't work perfectly for storing/reapplying my hardware configs). when i finally purchased my harddrive, i used badblocks on the knoppix cd to test my drive. it writes various binary patterns to each sector reading the sector back after each write to verify that the data is maintaining the specific binary pattern. i can't remember how many patterns there are, but assuming there are four different patterns, then each sector gets written to and read four times (once for each pattern), which itself is a pretty good stress test and burn-in.
assuming you are familiar with linux, see the man page for badblocks on the knoppix cd for how to do a destructive read/write test, repeating the test until there are no new bad sectors found. (there's also a read/write non-destructive test, where before each sector is written, it is stored in memory, and written back out after the individual sector is tested, but in my case this was a brand new drive so i had nothing to lose doing a destructive test.)
most newer machines with an on-board nic (my ecs k7s5a) support pxe boot as an option within the bios. but for older machines, net booting requires either a nic that supports net booting (should have an eeprom on the nic), which are not the cheap nics that i've always bought, or with a floppy (which can probably be burned to a cdr to make a bootable cd).
for net boot floppy images see the section "Making Boot Disks for Legacy PCs" in the k12ltsp client set-up instructions. those instructions reference the rom-o-matic website, which supplies dynamically-generated downloadable boot floppies using etherboot.
so for a small (1.44 MB) simple net boot solution for computers that don't support pxe booting, but with a floppy drive (or bootable from a cd), look at the k12ltsp instructions and visit the rom-o-matic website for a net boot floppy.
ps the images might even be on the knoppix cd as net boot floppy images are (sometimes?) distributed with ltsp, but probably not due to space constraints on the knoppix cd.
well, no surprise considering the pdf file was created with "Acrobat Distiller 5.0.5 (Windows)" and titled "Microsoft Word - PlatformServicesWP_031703". call me cheap, but even under windows i use win32 ghostscript to convert ps (generated by adobe's free-beer postscript driver using "print to file") to pdf. sure, using my poor man's method i don't get hyperlinks, but notice that none of the urls in the pdf are hyperlinks either, though i'm sure distiller is capable of such.
/ xfree86/xfree86_4.1.0-16/changelog), not a hacker, so it's understandable.
sure progeny's head is ian murdock of debian fame, but the doc seems to be authored by robin drake (rdrake), who seems to be a writer/editor (http://hackers.progeny.com/pgi/usermanual.html, http://changelogs.credativ.org/debian/pool/main/x
but yeah, it does look odd for a "linux" company to be using windows, but i won't go so far as to call it hypocritical.
is it a local isp? if not and regional/national, then they might service me here. (oh please!)
i would even be willing to pay $30/month for 128k-down, 64k-up, (semi-)unmetered access.
i currently pay $15/month for unmetered dial-up, but only get 28k due to lousy phone lines in my apt complex. (i've ran into this problem in every apt complex i've lived in, but then again if i paid $1k/month for a brand new upscale apt i would probably have better [newer] phone lines.)
i do my "apt-get dist-upgrade" downloads every night, so i'm not exasperated by how slow my "narrowband" connection is (except when libc gets updated and 50MB of packages flood testing all at once and cause that night's download to last into the daylight hours). i download isos from work, burn them, and bring them home, so no problem there. about the only thing i use my connection at home for is email and a limited amount of surfing. i do most of my surfing at work. though it's a bit of a pain to have to do everything at work, staying late at the office to purchase something online or research purchases.
purchasing stuff from online shops is a pain over narrowband. browsing different online stores to comparison shop is horribly slow with all the images (buttons, banners, imagemaps) they use. and on the weekends i hate having to get offline to use the telephone, or not be able to get online because i'm expecting a phone call (that may not come on time or even at all).
i don't want blazing speed. i just want to have an always-on connection, something significantly faster than my 28k dial-up, and around $30.
just one warning/suggestion
:0fw:spamassassin.lock
/proc/sys/fs/file-max. so i bumped up file-max. then i started running out of memory. (this is why spamd/spamc was created: to eliminate the overhead of multiple perl/spamassassin instances by having a single daemon do the processing.)
* 256000
| nice spamassassin -P
on my three year old laptop, the procmail rule suggested in the spamassassin docs (and pretty much the same as in the parent post) was a little too heavy on the cpu, so i added the nice command.
but that wasn't the only problem. i use fetchmail, which dumps all my fetched mail to exim, which (under debian, i believe) is automatically configured to pipe to procmail. the problem: spamassassin was being started for each email, concurrently. fetching 30 emails started 30 separate instances of spamassassin which quickly exceeded
finally i analyzed the problem and realized that i needed to serialize the process (for the sake of my laptop) as nothing yet had worked. i applied a lock file to the procmail rule (though i'm not sure specifying the lock file name is necessary but i didn't want to experiment and see if procmail could determine a name or not) and everything is okay except that processing email with spamassassin delays mail delivery (which usually isn't noticed when the mail is processed as it arrives except that i execute fetchmail manually after dialing into my isp so i know when fetchmail retrieves it and when it's finally available to be read a minute or two later), and even more so now that everything is serialized (though with a single spamassassin instance maxing out my cpu, i'm not sure multiple instances was that much faster).
oh, and as the updated spamassassin documentation says, you'll want to add the file size check, or that'll make you run out of memory too.
hope that helps somebody keep from having the same rocky initial experience as me.
this is great to see as this has been touted (by others and myself) to be where open source makes the most sense to a company: non-business-core computer software.
the weather channel's primary business is grabbing eyeballs (to sell itself to cable companies or to sell air-time through commercials during its segments) and it does that through weather forecasting.
video drivers are not the mainstay of their business, but definitely help them in their business. the weather channel doesn't care about selling video drivers. that's not their business. they just need video drivers. and they can pay someone else to create those video drivers and then give the source code away without "selling the farm": giving away a business secret to a competitor.
this would be the same as a music production company paying someone to produce open source drivers for a sound card. the company gets drivers, free support from the community, and yet doesn't give away its secrets or the upper hand to competitors. it's a win-win situation for the company and the community.
this is how i expect to see open source prevail in the future: companies paying for open source development that aids their business (but is not their sole business), and the action being justified by knowing that the open source community (that has an interest in the developed software) will support (to some degree) the software.
in the weather channel's case, this made perfect sense.
DING, DING, DING! WE HAVE A WINNER!
that's exactly what i do. my workstation at home has uw-imapd installed, and i can access my mail from any computer on my home network from any client that supports imap from any os.
the reason for this setup is because i wanted the flexibility to use any client and keep the interface to my mailboxes standardized (where some mail clients insist on their own mailbox format).
i was a eudora user for a LONG time (since windows 3.1 when you could carry eudora, your configuration, and recent email on a single 3.5" floppy) and that was the only thing keeping me chained to windows (dual-boot). i used eudora under wine, but it never looked the same and there was a different glitch with each new wine release. i wanted a linux native client.
first i researched a portable client for both linux and windows, but i didn't like any of the native clients and i'm not too crazy about what's required to set up a java runtime environment under linux and/or windows.
then i figured i would use the same imap server under both windows and linux, freeing me to use any client i wanted, and found a cygwin port of imapd, but the performance was horrid.
so finally i resolved to only use linux for my email platform (as i'm there 99% of the time), use imapd, and some undecided mail client. it was nice being able to try out different clients, and not having to convert/import my mail from one format/client to another, etc.
i've finally settled down with procmail, fetchmail, a script to manually kick-off fetchmail and also run mailstat, evolution (integrates with my handspring visor), and sometimes mutt if i just want to quickly read or lookup a message. if i get sent something for my wife, then i just log her into my imap account and transfer the email to her client (eudora) on her machine. this set-up works great.