Was there ever an updated/modernized version of Rocky's Boots? I remember that one VERY well as being something that got me into logic, circuits, and programming all in one place. Yes, I'm showing my age. Whippersnappers.
Nope, you misunderstand. I got them to issue one of the free certs for one of my domains (I use Gandi for all of my registrations), and it works perfectly with all major browsers out of the box. All you have to do is add Gandi's intermediate certificate (the cert that links their signature on your free cert to the base CA cert that's in everybody's browser), but you do that on your server (web/mail/whatever) and offer it up as part of the SSL negotiation. It works perfectly, and transparently. It is definitely NOT like the hassle of a self-signed certificate, where you DO have to either add the "security exception" to every client's browser, or get them to install your cert into their browser ahead of time.
People who care about their data and their business know what they mean.
Although, at my particular shop, we use the term "BC" instead of "HA". BC = Business Continuance (HA = High Availability) DR = Disaster Recovery
BC = "Looks like we just lost a drive in the array. Better replace that right away." or "Oops, broke one of the multiple fibers to the SAN. Where's the spare again?" BC also applies to our load-balanced clusters of web servers and application servers that allow for the offlining or loss of entire machines without losing functionality. You need more than your data existing on media to Continue Business - you and your customers need to be able to GET to it somehow.
DR = Your building just burned to the ground, taking every single piece of furniture, equipment, paper, and magnetic media inside along with it. Now what? Please note that the coolest, slickest, snapshotted NAS with terabytes and terabytes of awesome cheap SATA storage in it is worth exactly JACK in this scenario if it's in the same building as the source material. Offsite backups are not optional, and offsite storage of hard drives isn't exactly the easiest thing to do.
For that to work, you need a boot loader that supports zfs. This will come first in Solaris 10 x86 because they already have grub there. It's easier.
Actually, GP was talking about ZONE root filesystems, which have absolutely nothing to do with the bootloader, since the zone runs on top of the underlying global zone. You CAN put a zone root on ZFS at the moment, but Sun neither recommends nor supports that setup.
For SPARC machines, it'll require new OpenBoot firmware that understands zfs.
And this is simply untrue, period, even for non-zone ZFS root filesystems. OpenBoot loads the next stage of boot code by reading raw data from blocks 1-8 of the chosen slice of the boot disk, and THAT is the code that needs to be able understand the filesystem that will be mounted as root (UFS, ZFS, or whatever). OpenBoot only needs to understand the disk label/partitioning and to be able to read the disk blocks. It already does that, so non-zone ZFS root will NOT require any modifications or upgrades to OpenBoot, just updates to the bootloader code that is written to the disk in blocks 1-8.
Another vote for this one. Replicate the database and give them R/O access to the replicated DB. They can't overload the primary database, and if they manage to screw it up (shouldn't happen with R/O, but you never know), you can just refresh from the master.
See the many postings below this about how many people are blocking thousands of mails at the front door BEFORE subjecting them to resource-intense or flaky at best filtering solutions.
If they've already shut down, I guess that explains the rather sudden and rather LARGE increase in spam I had sitting in my various mailboxes waiting for me this morning.:(
Can anyone suggest a good alternative? I'm using spamhaus, sorbs, and uceprotect at the moment, and no, I won't use spamcop. ordb HAD been an excellent fourth.
Sorry, I've never used djbdns, so I'll have to defer to someone else that knows how to implement the above change (assuming it's even possible) with it. Anyone?
I just make sure to run the latest BIND 9.x as an unprivileged user in a chroot jail. Hasn't been an issue so far.
If I double-click a track to play it, then click advance, it was always advancing to a different track, implying that it reshuffled at the point of selecting a track. Simply moving backwards and forwards between tracks left them in a consistent order, however.
That's been my experience as well (the "random" playback order is consistent until you manually choose a track).
In the spirit of the article, regarding noticing patterns where there really aren't any, it's been my perception with XMMS that it tends to pick "pairs" of songs. That is, for any given track it plays at random, the chance of the next "random" track being from the same artist seems to be significantly higher. I have an XMMS playlist of over 2000 tracks, with literally hundreds of artists, and yet when a track from any particular artist plays, the next track is also from that artist far more often than not. I've often wondered if the particular random algorithm that was chosen for XMMS doesn't have a preference for two numbers close to each other, then farther apart, etc. since I generally keep my playlist sorted by artist.
And I hope you understand that I actually - gasp! - bought the CD and ripped and encoded it all by myself. I know, I know - it was a moment of weakness, and I really hate myself for having done it. I'll try not to let it happen again</sarcasm>
Seriously, though, I have no regrets having bought this album or any others out of the small handful of original, pressed, expensive CDs I've purchased in the last few years. But in almost each and every case, I've come across the tracks online somewhere, downloaded them and given them a test listen before the cashola left my pockets. If the RIAA had their way, I'd be out several million dollars in legal penalties, and maybe behind bars. I just don't get that.
Back to the original point. Bands that are getting started and want exposure: pick a good cover song, and include it alongside your original material. You WILL get more attention that way. Just do us all a favor, and don't destroy the memory of the original by doing such a fantastically bad job of covering it that we end up hating both your version and the original as a result! Case in point - Marilyn Manson's "Sweet Dreams (are Made of This)". If you enjoy the original, for the love of god, don't listen to this "cover".
Oddly, I never knew if this one got much airplay, since I haven't intentionally listened to the radio (at least for music) in something like a decade or more. I stumbled across it while looking for the original Don Henley version. See my reply to mcocke below for musings on the RIAA's attitude about that.
Glad to hear it. My inclusion of the track/album/artist info WAS in fact a subtle attempt to maybe see if anyone else would go check it out.
But yeah, I still don't understand the well-entrenched belief in the recording industry that downloading tracks always costs them money and is pure, unadulterated theft. I found the Ataris track while looking for a copy of the Don Henley version. I downloaded it. I liked it. I then went and dropped my genuine, hard-earned CASH on a genuine, pressed CD! Scary, I know. Sorry, RIAA, I don't know what came over me. Next time I won't bother giving you or your artists or your distributors any cash, and you can go on ranting about being ripped off, okay?
Interesting side note on that album. The Ataris included the full lyrics to all of their tracks in the liner notes, something I really appreciate when it happens. But oddly, the lyrics to "Boys of Summer" were left out. I wonder if there was some legal restriction on their inclusion?
I'm advising all musicians I know to include one good creative (not-too-covered, not-too-obscure) cover song on their future albums, to help call attention to it in this song-based search world.
This is VERY good advice. I bought The Ataris' So Long, Astoria *specifically* because of the well-done cover of Don Henley's "Boys of Summer" it had. Turns out the rest of the album was pretty good, and it remains planted on my playlist (after the requisite ripping to 320K.mp3, of course).
Give the man a cigar (or a mod up if you happen to have the points).
I've been responsible for tape backups in most of the positions I've held over the last 12 years or so. I've worked with most of the major tape formats including QIC, 4mm DDS, 8mm, AIT, DLT, and LTO.
I'm currently using an IBM 3584 with 3xLTO2 drives. It's almost a pleasure to work with. It doesn't jam. It doesn't lose track of what tapes it has loaded. It's fairly fast. Every other autoloader I've ever worked with has been a pain. ESPECIALLY the DLT loaders. I don't think I've EVER seen a DLT drive last longer than a year before simply crapping out and needing to be replaced. I can count almost a dozen DLT drive failures I've had to cope with. I have yet - in 3 years of continuous use - to physically lose an LTO drive (although I admit all three of mine did lock up at one point due to a firmware bug).
I've also suffered with all of the major backup packages including ArcServe, BackupExec, NetBackup, Legato, and TSM. You know what I've discovered about choosing backup software? It's like picking who to vote for in an election. It's impossible to pick ANY of them based on any sort of positive criteria. You simply have to settle for the one that SUCKS the LEAST. And after being forced to use all of these packages, I can say without a doubt that TSM far and away sucks the least of all of them. You could not pay me enough to run a backup system based on NetBackup EVER again. I wouldn't trust it (or most of the other alleged "backup" systems) with data that had ANY value to me or my employer, whatsoever. I've seen more than one NetBackup installation simply implode, taking the entire catalog with it and needing to basically be rebuilt from scratch, having each and every tape in the inventory re-cataloged from beginning to end. And even when the catalog was still intact, I've had less than a 70% success rate in getting NetBackup to actually RESTORE something I needed restored. Almost a third of my attempts to get data back out of a NetBackup backup system resulted in random, unexplainable failures with cryptic numeric result codes that basically translated to "unknown internal error" according to the docs. On the other end of the spectrum, using TSM, I've successfully restored whole directory trees that were accidentally deleted in just a few minutes, whole Oracle databases that were damaged beyond recovery in a few hours, and I've done a bare-metal restore of both a complete Solaris server and a complete Novell server to a fully functional state in less than 4 hours each. Those last two were scheduled recovery exercises - I don't have ACTUAL failures that need restores very often. We have a bare-metal restore DR exercise for a Windows 2000 system scheduled for the early part of next month, and I expect it will work almost as easily as the other two.
Plus with TSM's Disaster Recovery Manager feature, offsite tape management is brain-dead simple. The system automatically keeps one copy of your data hot and ready in the tape changer on-site, so restores of accidentally deleted or corrupted files/databases can happen immediately, and another copy is fully maintained and rotated to offsite storage by the DRM for a disaster scenario in which the on-site equipment is destroyed. The daily outbound and call-back reports are generated automatically, and plugging them into the offsite storage company's infrastructure is pretty easy. All I usually have to do is take the tapes out of the changer, and put the call-backs in the changer when they're dropped off.
With my current 3584(LTO)/TSM setup, I can safely say - for the first time in over a *decade* of working as a system admin - that I am TOTALLY confident in my ability to restore our data center to 100% functionality in a total-loss scenario. I'd love to find out how many SysAdmins working with any other backup technology have that same level of confidence. I know I personally never had this level of confidence in my backups with any other backup software, and I was always at least a little concerned when using the other tape formats.
First, thank you for a reasoned and sane response.
This sounds very similar to the feedback I got from a friend/ex-coworker who is now a paid security consultant. The way he explained it was (paraphrasing): "While you may have taken steps to mitigate the risk of use of the SSH tunnels as an attack vector, and while that mitigation may even be stronger than what's in place for the VPN/home user/travelling laptop attack vector, the fact that those responsible for securing the enterprise are unaware of the SSH attack vector's existence tends to make it a higher risk factor because it is neither being monitored nor responded to if such an attack occurs."
So it looks like I'll be discussing my requirements with those responsible for the VPN yet again, and seeing if they'll either 1) fix the damn VPN client, or 2) acknowledge/approve my solution. But I remain firmly convinced that I'm far and away the most security-conscious person that works here. Period. Sigh.
Then I came to the conclusion that he probably doesn't work for a publicly-traded company.
Tell you the truth, I actually don't know. I'd wager you're right, we're probably privately held.
... who is most at fault. His employer for not taking IT seriously...him for violating good security practices...or the company they hired to "audit" him who passed him without an existing IT policy.
All of the above. IT *isn't* taken seriously here, you're right. That will change soon, I can assure you. For lots of reasons.
As for the audit, I/my division passed, but other divisions didn't fare so well. On the Windows side of the house, where the auditors discovered that the administrator password on a publicly exposed Citrix server was just the company name, and that there was a trust relationship between it and the internal systems... Well, hey, they didn't pass. Imagine that. Oh, and the password on all the external routers was the same. Yay.
I'm genuinely curious, though, and looking for a sane, reasoned response like this one was. Aside from the fact that my SSH usage doesn't use the "company-purchased-and-installed" VPN solution, how is the creation/use of an SSH-encrypted tunnel over the Internet between two identically hardened, identically firewalled UNIX systems a "bad security practice"? The VPN users ride the same public Internet that I do. They have to use the same passwords to authenticate that I do. And most of our VPN user connections originate from unsecured, unfirewalled Windows systems (think laptops/road warriors). What is the magic of a VPN that miraculously makes it perfect and infallible, while SSH is simultaneously security swiss cheese and 100% unacceptable? Is the sole objection to tunnelling the fact that is isn't sanctioned, or is there a genuine, TECHNICAL fallacy here that I'm overlooking? I admit my solution isn't sanctioned. That's a political battle for me to deal with when and if it becomes an issue. What's the technical objection, if there is any? I'm 100% serious - I admit I may be ignorant, so educate me. Oh, and saying "If you don't just KNOW the answer, you shouldn't have anything to do with security, you stupid git!" not only avoids the question, it's flamebait to boot.
Since this was supposed to be a How-To article, all pissing and moaning about security concerns aside, here's my two configs, obfuscated as is obviously necessary:
The 8080 LocalForward lets me hit the proxy running on unix.machine.home. The 5900 LocalForward lets me use VNC on to access windows.machine.home. The 45678 RemoteForward lets me "call back" to the work machine on port 22 (ssh, of course). LocalForward by default binds to 127.0.0.1. I also specifically use 127.0.0.1 bindings on the RemoteForward to restrict access to the tunnel to people who are already on the system. In a perfect world, that's just me.
This "calls back" using the outbound tunnel established from work. The 1580 LocalForward lets me reach my backup server to operate the tape backup system. The 8080 LocalForward lets me view my Nagios monitoring system. The 143 LocalForward lets me get to my Exchange E-Mail (over IMAP). As mentioned, LocalForward binds to 127.0.0.1 for listening, leaving these tunnels only accessible to people with shell-level access to the machines involved (again, that should just be me).
Clean, effective, and very useful. I can basically be just as productive sitting at home as sitting in front of the workstation at work.
It's no biggie, my current setup works fine. But I have to admit that's a pretty cool feature. It's probably specific to OpenSSH. We aren't using OpenSSH here and I don't use it at home.
That's a really bad idea. You're just asking to get fired.
Not really. The company hasn't had an Information Security Policy since I started. We're in the middle of drafting one right now. Guess who's writing it? Yep, ME. And as for our last audit, I was the one working with the auditors. We passed.
For everyone who thinks I'm putting the company at risk:
1) My machine at home is behind a firewall. A real, separate, dedicated, hardware firewall - not some wanna-be software filter running locally.
2) I know for a fact there are people running Kazaa on their desktop machines here at work. Yes, the new ISP will address that issue.
I *really* hope my employer doesn't recognize my Slashdot ID.:)
I use an SSH tunnel to forward port 8080 on my desktop machine here at work to port 8080 on my Unix workstation at home that's running an HTTP proxy. I set my Firefox/Mozilla at work to use localhost as its proxy, and I now happily bypass any and all logging and/or site restrictions on my work browsing habits.
I also remote-forward a pseudo-random high port on that remote workstation at home to port 22 on my work desktop machine, giving me the ability to SSH *back in* to work from home, and not monkey with the company's VPN solution that has a client for my home machine that's so buggy it's unreal. That remote SSH call-back also forwards the home machine's IMAP port to the company's Exchange Server so I can read my email over the tunnel, and I port-forward to our network monitoring and backup systems' web interfaces so I can actually do my job.
I guess I can say that my productivity from home would be pretty much zippo if I didn't have SSH tunnels at my disposal.
Seriously not trying to be flamebait here. We'll see if the mods disagree.
requiring 3 - 5% or better tolerance is not acceptable. We had to hand-match Apple ][ drives back in '77 to ensure that the two drives could exchange data.
These were drives that took 200ms (yes, that's.2 seconds) per revolution. They had a trim-pot for speed adjustment and you had to put several turns on it to get the drive far enough out of spec to misread disks. Hundreds of Disk II drives have passed through my possession, and I've never had to match their speeds to that level unless I was dealing specifically with a bitchy, temperamental nibble-count protected disk - and those were somewhat rare. Standard 16-sector format Apple II disks were phenomenally tolerant of speed variation. I respectfully submit that your memory likely exceeds your experience in this case.
As to "100%" reliable... it is possible to "accidentally" record a data pattern that duplicates the synchronization header. Just about the only system that this was possible on was the Apple ][.
The sector header (and there was one for EVERY sector, not one per track) consisted of 3-byte prologue (D5 AA 96) that used unique byte values that were not possible to generate using the standard 5&3 encoding scheme, followed by the track, sector and volume number 4&4 encoded into 6 bytes, followed by a checksum byte 4&4 encoded into two bytes, followed by a two-byte epilogue (DE AA) also using unique values not possible from the standard 5&3 encoding. If the checksum didn't validate those volume, track and sector values, the header was considered no good and ignored.
Yes, it is possible to "accidentally" record a pattern that would duplicate such a header. It's also possible (and probably just as likely) to throw a Scrabble set in the air and get Shakespeare.:)
However, saving the expense of (1) a proper floppy controller, (2) a proper video generator, (3) delegating everything to the 6502, did make the machine remarkably affordable.
Now this, I can agree with 110%. As a bonus, it also made the machine remarkably FLEXIBLE as well. There was very little - if anything - that the hardware prevented you from doing. The Apple II was a true "hacker's" machine, in the spirit of the original meaning of the word.
Just not remarkably dependable.
For unusual values of dependable, maybe.:) I have dozens of Apple//e's, Super Serial Cards, Disk II drives & controllers, all of which are 20+ years old and all of which are still as functional as the day they were built. How many other systems from that era are anything but dumpster fodder right now?
PS. U an looking for an Apple ][ DOS 3.3 boot disk. Email me if you can make me a copy.
I use ProDOS for the most part, especially since I only have a IIgs set up active at the moment. Not to mention DOS 3.3 support for hard drives is dismal at best. I'd have to dig for a bit to get you a DOS 3.3 disk. However, I do know people that could readily provide you one, and I'd be happy to get you set up.
Also, consider dropping by comp.sys.apple2 if talk of these older machines (and what they're still being actively used for today, like this incredibly cool project) is appealing to you.
Which meant that the drives had to be almost EXACTLY the same rotational speed, or they couldn't exchange disks.
Not necessarily. Because of the use of self-sync bytes and a required set high-bit for any disk byte, the software decode was remarkably tolerant of speed variations on the drives. I saw Apple II drives whose speeds were 2-3% off from spec still operate perfectly, including exchanging disks with other systems.
if a sector is damaged, it is possible to skip over it, and read sectors after it on the same track. Not possible (with ANY reliability) using a soft-sector format.
Also not true. The Apple II's disk-encoding scheme had a header preceding each sector, with sufficient information to synchronize with and identify each sector 100% reliably, regardless of the condition of any other sector on that track. It was quite possible to have 15 of 16 sectors on an Apple II disk perfectly (and consistently) readable.
Slashdot Mirror
Was there ever an updated/modernized version of Rocky's Boots? I remember that one VERY well as being something that got me into logic, circuits, and programming all in one place. Yes, I'm showing my age. Whippersnappers.
Nope, you misunderstand. I got them to issue one of the free certs for one of my domains (I use Gandi for all of my registrations), and it works perfectly with all major browsers out of the box.
All you have to do is add Gandi's intermediate certificate (the cert that links their signature on your free cert to the base CA cert that's in everybody's browser), but you do that on your server (web/mail/whatever) and offer it up as part of the SSL negotiation. It works perfectly, and transparently. It is definitely NOT like the hassle of a self-signed certificate, where you DO have to either add the "security exception" to every client's browser, or get them to install your cert into their browser ahead of time.
People who care about their data and their business know what they mean.
Although, at my particular shop, we use the term "BC" instead of "HA".
BC = Business Continuance (HA = High Availability)
DR = Disaster Recovery
BC = "Looks like we just lost a drive in the array. Better replace that right away." or "Oops, broke one of the multiple fibers to the SAN. Where's the spare again?"
BC also applies to our load-balanced clusters of web servers and application servers that allow for the offlining or loss of entire machines without losing functionality. You need more than your data existing on media to Continue Business - you and your customers need to be able to GET to it somehow.
DR = Your building just burned to the ground, taking every single piece of furniture, equipment, paper, and magnetic media inside along with it. Now what?
Please note that the coolest, slickest, snapshotted NAS with terabytes and terabytes of awesome cheap SATA storage in it is worth exactly JACK in this scenario if it's in the same building as the source material. Offsite backups are not optional, and offsite storage of hard drives isn't exactly the easiest thing to do.
For that to work, you need a boot loader that supports zfs. This will come first in Solaris 10 x86 because they already have grub there. It's easier.
Actually, GP was talking about ZONE root filesystems, which have absolutely nothing to do with the bootloader, since the zone runs on top of the underlying global zone. You CAN put a zone root on ZFS at the moment, but Sun neither recommends nor supports that setup.
For SPARC machines, it'll require new OpenBoot firmware that understands zfs.
And this is simply untrue, period, even for non-zone ZFS root filesystems. OpenBoot loads the next stage of boot code by reading raw data from blocks 1-8 of the chosen slice of the boot disk, and THAT is the code that needs to be able understand the filesystem that will be mounted as root (UFS, ZFS, or whatever). OpenBoot only needs to understand the disk label/partitioning and to be able to read the disk blocks. It already does that, so non-zone ZFS root will NOT require any modifications or upgrades to OpenBoot, just updates to the bootloader code that is written to the disk in blocks 1-8.
Another vote for this one. Replicate the database and give them R/O access to the replicated DB. They can't overload the primary database, and if they manage to screw it up (shouldn't happen with R/O, but you never know), you can just refresh from the master.
Thanks. Couldn't have said it better myself.
See the many postings below this about how many people are blocking thousands of mails at the front door BEFORE subjecting them to resource-intense or flaky at best filtering solutions.
And my original question still stands.
If they've already shut down, I guess that explains the rather sudden and rather LARGE increase in spam I had sitting in my various mailboxes waiting for me this morning. :(
Can anyone suggest a good alternative? I'm using spamhaus, sorbs, and uceprotect at the moment, and no, I won't use spamcop. ordb HAD been an excellent fourth.
Sorry, I've never used djbdns, so I'll have to defer to someone else that knows how to implement the above change (assuming it's even possible) with it. Anyone?
I just make sure to run the latest BIND 9.x as an unprivileged user in a chroot jail. Hasn't been an issue so far.
So go ahead and pull their domain from the DNS hierarchy.
/etc/named.conf
# cat >>
zone "spamhaus.org" in {
type forward;
forwarders {216.168.28.44; 204.69.234.1; 204.74.101.1; 204.152.184.186; };
};
^D
# pkill -HUP named
All fixed!!
That's been my experience as well (the "random" playback order is consistent until you manually choose a track).
In the spirit of the article, regarding noticing patterns where there really aren't any, it's been my perception with XMMS that it tends to pick "pairs" of songs. That is, for any given track it plays at random, the chance of the next "random" track being from the same artist seems to be significantly higher. I have an XMMS playlist of over 2000 tracks, with literally hundreds of artists, and yet when a track from any particular artist plays, the next track is also from that artist far more often than not. I've often wondered if the particular random algorithm that was chosen for XMMS doesn't have a preference for two numbers close to each other, then farther apart, etc. since I generally keep my playlist sorted by artist.
And I hope you understand that I actually - gasp! - bought the CD and ripped and encoded it all by myself. I know, I know - it was a moment of weakness, and I really hate myself for having done it. I'll try not to let it happen again</sarcasm>
Seriously, though, I have no regrets having bought this album or any others out of the small handful of original, pressed, expensive CDs I've purchased in the last few years. But in almost each and every case, I've come across the tracks online somewhere, downloaded them and given them a test listen before the cashola left my pockets. If the RIAA had their way, I'd be out several million dollars in legal penalties, and maybe behind bars. I just don't get that.
Back to the original point. Bands that are getting started and want exposure: pick a good cover song, and include it alongside your original material. You WILL get more attention that way. Just do us all a favor, and don't destroy the memory of the original by doing such a fantastically bad job of covering it that we end up hating both your version and the original as a result! Case in point - Marilyn Manson's "Sweet Dreams (are Made of This)". If you enjoy the original, for the love of god, don't listen to this "cover".
Oddly, I never knew if this one got much airplay, since I haven't intentionally listened to the radio (at least for music) in something like a decade or more. I stumbled across it while looking for the original Don Henley version. See my reply to mcocke below for musings on the RIAA's attitude about that.
Glad to hear it. My inclusion of the track/album/artist info WAS in fact a subtle attempt to maybe see if anyone else would go check it out.
But yeah, I still don't understand the well-entrenched belief in the recording industry that downloading tracks always costs them money and is pure, unadulterated theft. I found the Ataris track while looking for a copy of the Don Henley version. I downloaded it. I liked it. I then went and dropped my genuine, hard-earned CASH on a genuine, pressed CD! Scary, I know. Sorry, RIAA, I don't know what came over me. Next time I won't bother giving you or your artists or your distributors any cash, and you can go on ranting about being ripped off, okay?
Interesting side note on that album. The Ataris included the full lyrics to all of their tracks in the liner notes, something I really appreciate when it happens. But oddly, the lyrics to "Boys of Summer" were left out. I wonder if there was some legal restriction on their inclusion?
I'm advising all musicians I know to include one good creative (not-too-covered, not-too-obscure) cover song on their future albums, to help call attention to it in this song-based search world.
.mp3, of course).
This is VERY good advice. I bought The Ataris' So Long, Astoria *specifically* because of the well-done cover of Don Henley's "Boys of Summer" it had. Turns out the rest of the album was pretty good, and it remains planted on my playlist (after the requisite ripping to 320K
Give the man a cigar (or a mod up if you happen to have the points).
I've been responsible for tape backups in most of the positions I've held over the last 12 years or so. I've worked with most of the major tape formats including QIC, 4mm DDS, 8mm, AIT, DLT, and LTO.
I'm currently using an IBM 3584 with 3xLTO2 drives. It's almost a pleasure to work with. It doesn't jam. It doesn't lose track of what tapes it has loaded. It's fairly fast. Every other autoloader I've ever worked with has been a pain. ESPECIALLY the DLT loaders. I don't think I've EVER seen a DLT drive last longer than a year before simply crapping out and needing to be replaced. I can count almost a dozen DLT drive failures I've had to cope with. I have yet - in 3 years of continuous use - to physically lose an LTO drive (although I admit all three of mine did lock up at one point due to a firmware bug).
I've also suffered with all of the major backup packages including ArcServe, BackupExec, NetBackup, Legato, and TSM. You know what I've discovered about choosing backup software? It's like picking who to vote for in an election. It's impossible to pick ANY of them based on any sort of positive criteria. You simply have to settle for the one that SUCKS the LEAST. And after being forced to use all of these packages, I can say without a doubt that TSM far and away sucks the least of all of them. You could not pay me enough to run a backup system based on NetBackup EVER again. I wouldn't trust it (or most of the other alleged "backup" systems) with data that had ANY value to me or my employer, whatsoever. I've seen more than one NetBackup installation simply implode, taking the entire catalog with it and needing to basically be rebuilt from scratch, having each and every tape in the inventory re-cataloged from beginning to end. And even when the catalog was still intact, I've had less than a 70% success rate in getting NetBackup to actually RESTORE something I needed restored. Almost a third of my attempts to get data back out of a NetBackup backup system resulted in random, unexplainable failures with cryptic numeric result codes that basically translated to "unknown internal error" according to the docs. On the other end of the spectrum, using TSM, I've successfully restored whole directory trees that were accidentally deleted in just a few minutes, whole Oracle databases that were damaged beyond recovery in a few hours, and I've done a bare-metal restore of both a complete Solaris server and a complete Novell server to a fully functional state in less than 4 hours each. Those last two were scheduled recovery exercises - I don't have ACTUAL failures that need restores very often. We have a bare-metal restore DR exercise for a Windows 2000 system scheduled for the early part of next month, and I expect it will work almost as easily as the other two.
Plus with TSM's Disaster Recovery Manager feature, offsite tape management is brain-dead simple. The system automatically keeps one copy of your data hot and ready in the tape changer on-site, so restores of accidentally deleted or corrupted files/databases can happen immediately, and another copy is fully maintained and rotated to offsite storage by the DRM for a disaster scenario in which the on-site equipment is destroyed. The daily outbound and call-back reports are generated automatically, and plugging them into the offsite storage company's infrastructure is pretty easy. All I usually have to do is take the tapes out of the changer, and put the call-backs in the changer when they're dropped off.
With my current 3584(LTO)/TSM setup, I can safely say - for the first time in over a *decade* of working as a system admin - that I am TOTALLY confident in my ability to restore our data center to 100% functionality in a total-loss scenario. I'd love to find out how many SysAdmins working with any other backup technology have that same level of confidence. I know I personally never had this level of confidence in my backups with any other backup software, and I was always at least a little concerned when using the other tape formats.
"I'm big boned!"
"You're big-ASSED, okay? Dinosaurs are big-boned. Put the fork down!"
"I'm not actually overeating - I'm trying to keep the virus at bay!"
Arararararar!
From a little over a year ago
It's nice to see that nothing has changed as far as the banks go.
First, thank you for a reasoned and sane response.
This sounds very similar to the feedback I got from a friend/ex-coworker who is now a paid security consultant. The way he explained it was (paraphrasing): "While you may have taken steps to mitigate the risk of use of the SSH tunnels as an attack vector, and while that mitigation may even be stronger than what's in place for the VPN/home user/travelling laptop attack vector, the fact that those responsible for securing the enterprise are unaware of the SSH attack vector's existence tends to make it a higher risk factor because it is neither being monitored nor responded to if such an attack occurs."
So it looks like I'll be discussing my requirements with those responsible for the VPN yet again, and seeing if they'll either 1) fix the damn VPN client, or 2) acknowledge/approve my solution. But I remain firmly convinced that I'm far and away the most security-conscious person that works here. Period. Sigh.
All of the above. IT *isn't* taken seriously here, you're right. That will change soon, I can assure you. For lots of reasons.
As for the audit, I/my division passed, but other divisions didn't fare so well. On the Windows side of the house, where the auditors discovered that the administrator password on a publicly exposed Citrix server was just the company name, and that there was a trust relationship between it and the internal systems... Well, hey, they didn't pass. Imagine that. Oh, and the password on all the external routers was the same. Yay.
I'm genuinely curious, though, and looking for a sane, reasoned response like this one was. Aside from the fact that my SSH usage doesn't use the "company-purchased-and-installed" VPN solution, how is the creation/use of an SSH-encrypted tunnel over the Internet between two identically hardened, identically firewalled UNIX systems a "bad security practice"? The VPN users ride the same public Internet that I do. They have to use the same passwords to authenticate that I do. And most of our VPN user connections originate from unsecured, unfirewalled Windows systems (think laptops/road warriors). What is the magic of a VPN that miraculously makes it perfect and infallible, while SSH is simultaneously security swiss cheese and 100% unacceptable? Is the sole objection to tunnelling the fact that is isn't sanctioned, or is there a genuine, TECHNICAL fallacy here that I'm overlooking? I admit my solution isn't sanctioned. That's a political battle for me to deal with when and if it becomes an issue. What's the technical objection, if there is any? I'm 100% serious - I admit I may be ignorant, so educate me. Oh, and saying "If you don't just KNOW the answer, you shouldn't have anything to do with security, you stupid git!" not only avoids the question, it's flamebait to boot.
Since this was supposed to be a How-To article, all pissing and moaning about security concerns aside, here's my two configs, obfuscated as is obviously necessary:
Work-side
---------
proxy:
Host unix.machine.home
LocalForward 8080:unix.machine.home:8080
LocalForward 5900:windows.machine.home:5900
RemoteForward 127.0.0.1:45678:127.0.0.1:22
The 8080 LocalForward lets me hit the proxy running on unix.machine.home.
The 5900 LocalForward lets me use VNC on to access windows.machine.home.
The 45678 RemoteForward lets me "call back" to the work machine on port 22 (ssh, of course).
LocalForward by default binds to 127.0.0.1. I also specifically use 127.0.0.1 bindings on the RemoteForward to restrict access to the tunnel to people who are already on the system. In a perfect world, that's just me.
Home-side
---------
callback:
Host localhost
Port 45678
LocalForward 1580:backup.server.work:1580
LocalForward 8080:nagios.server.work:80
LocalForward 143:exchange.server.work:143
This "calls back" using the outbound tunnel established from work.
The 1580 LocalForward lets me reach my backup server to operate the tape backup system.
The 8080 LocalForward lets me view my Nagios monitoring system.
The 143 LocalForward lets me get to my Exchange E-Mail (over IMAP).
As mentioned, LocalForward binds to 127.0.0.1 for listening, leaving these tunnels only accessible to people with shell-level access to the machines involved (again, that should just be me).
Clean, effective, and very useful. I can basically be just as productive sitting at home as sitting in front of the workstation at work.
For everyone who thinks I'm putting the company at risk:
1) My machine at home is behind a firewall. A real, separate, dedicated, hardware firewall - not some wanna-be software filter running locally.
2) I know for a fact there are people running Kazaa on their desktop machines here at work. Yes, the new ISP will address that issue.
I *really* hope my employer doesn't recognize my Slashdot ID. :)
I use an SSH tunnel to forward port 8080 on my desktop machine here at work to port 8080 on my Unix workstation at home that's running an HTTP proxy. I set my Firefox/Mozilla at work to use localhost as its proxy, and I now happily bypass any and all logging and/or site restrictions on my work browsing habits.
I also remote-forward a pseudo-random high port on that remote workstation at home to port 22 on my work desktop machine, giving me the ability to SSH *back in* to work from home, and not monkey with the company's VPN solution that has a client for my home machine that's so buggy it's unreal. That remote SSH call-back also forwards the home machine's IMAP port to the company's Exchange Server so I can read my email over the tunnel, and I port-forward to our network monitoring and backup systems' web interfaces so I can actually do my job.
I guess I can say that my productivity from home would be pretty much zippo if I didn't have SSH tunnels at my disposal.
requiring 3 - 5% or better tolerance is not acceptable. We had to hand-match Apple ][ drives back in '77 to ensure that the two drives could exchange data.
These were drives that took 200ms (yes, that's .2 seconds) per revolution. They had a trim-pot for speed adjustment and you had to put several turns on it to get the drive far enough out of spec to misread disks.
Hundreds of Disk II drives have passed through my possession, and I've never had to match their speeds to that level unless I was dealing specifically with a bitchy, temperamental nibble-count protected disk - and those were somewhat rare. Standard 16-sector format Apple II disks were phenomenally tolerant of speed variation. I respectfully submit that your memory likely exceeds your experience in this case.
As to "100%" reliable... it is possible to "accidentally" record a data pattern that duplicates the synchronization header. Just about the only system that this was possible on was the Apple ][.
The sector header (and there was one for EVERY sector, not one per track) consisted of 3-byte prologue (D5 AA 96) that used unique byte values that were not possible to generate using the standard 5&3 encoding scheme, followed by the track, sector and volume number 4&4 encoded into 6 bytes, followed by a checksum byte 4&4 encoded into two bytes, followed by a two-byte epilogue (DE AA) also using unique values not possible from the standard 5&3 encoding. If the checksum didn't validate those volume, track and sector values, the header was considered no good and ignored.
Yes, it is possible to "accidentally" record a pattern that would duplicate such a header. It's also possible (and probably just as likely) to throw a Scrabble set in the air and get Shakespeare. :)
However, saving the expense of (1) a proper floppy controller, (2) a proper video generator, (3) delegating everything to the 6502, did make the machine remarkably affordable.
Now this, I can agree with 110%. As a bonus, it also made the machine remarkably FLEXIBLE as well. There was very little - if anything - that the hardware prevented you from doing. The Apple II was a true "hacker's" machine, in the spirit of the original meaning of the word.
Just not remarkably dependable.
For unusual values of dependable, maybe. :) I have dozens of Apple //e's, Super Serial Cards, Disk II drives & controllers, all of which are 20+ years old and all of which are still as functional as the day they were built. How many other systems from that era are anything but dumpster fodder right now?
PS. U an looking for an Apple ][ DOS 3.3 boot disk. Email me if you can make me a copy.
I use ProDOS for the most part, especially since I only have a IIgs set up active at the moment. Not to mention DOS 3.3 support for hard drives is dismal at best. I'd have to dig for a bit to get you a DOS 3.3 disk. However, I do know people that could readily provide you one, and I'd be happy to get you set up.
Also, consider dropping by comp.sys.apple2 if talk of these older machines (and what they're still being actively used for today, like this incredibly cool project) is appealing to you.
Which meant that the drives had to be almost EXACTLY the same rotational speed, or they couldn't exchange disks.
Not necessarily. Because of the use of self-sync bytes and a required set high-bit for any disk byte, the software decode was remarkably tolerant of speed variations on the drives. I saw Apple II drives whose speeds were 2-3% off from spec still operate perfectly, including exchanging disks with other systems.
if a sector is damaged, it is possible to skip over it, and read sectors after it on the same track. Not possible (with ANY reliability) using a soft-sector format.
Also not true. The Apple II's disk-encoding scheme had a header preceding each sector, with sufficient information to synchronize with and identify each sector 100% reliably, regardless of the condition of any other sector on that track. It was quite possible to have 15 of 16 sectors on an Apple II disk perfectly (and consistently) readable.
$60 is an RTS and $EA is a NOP. Both were very handy for "shunting" around the various copy-protection schemes in use on old Apple ][ programs.
I can't count the number of times I sector-edited in a sequence of "EA EA EA" somewhere.