Tweeter is another command line script that can update your Twitter status from the command line. It also uses the SSL link to protect your username and password. Tweeter can only post a new status; it cannot follow anyhone, send direct messages, or anything else. The username and password are not stored on the file system, so you can post to different accounts with ease. It should also work on older machines.
'blaze' is a Netfilter iptables firewall script that is meant to be ridiculously easy to use, pretty basic, but powerful enough to handle a box with multiple NICs to support gateway usage, possibly with NAT. Setup should take no more than five minutes. Logging is not currently supported.
auth2x is a Perl module for performing 2-factor authentication. auth2x has a user authenticate with a passphrase initially. If that authenticates, the module sends a 10 character hex code to a pre-configured (per authentication user-basis) email address. The user then authenticates a second time with their passphrase concatenated with the 10 character code.
fnf is a script that provides a list of a Twitter user's friends and followers. If you provide a username (and optional proxy), fnf will generate two files: USERNAME.followers and USERNAME.friends, consisting of a list of Twitter screen names and real names separated by " :: ". This data is easily used in scripts or imported to spreadsheets.
Vault is a Perl script to store away files, including metadata and integrity checks. Any file you want to keep, you put into a vault. This vault is just a directory. You can create any directory hierarchy allowed by your filesystem, and when you "vault" a file to a destination directory, a subdirectory is also created to store metadata files containing the MD5 hash of the file, the date it was vaulted, and any notes (i.e., metadata) you want to save regarding the file.
Re: I think this is a bad idea
> The Registry isn't in one file, but each
> folder is an
> actual folder, and each key is a file.
> That means it can
> use the filesystem's security.
Holy cow!!!!! One of the comments above stated that each program having its own config file results in a fat and bulky system. Now, its being suggested that not only each program be included in a single registry, but *EACH KEY BE ITS OWN FILE*?!?!?!? And this isn't fat and bulky?
From a configuration managment this may seem like a good idea, but from a technical standpoint, the filesystem is going to suffer. Plus, managing 100+ machines still isn't helped. For that matter, why not go one step further and instead of a system registry, make a network-based registry to house all the settings of all machines in one location.
I agree that standard text files are still optimal. They are conducive to virutally *any* means of management. The registry requires an API, text files require human eyes...nothing more. Any scripting language can be used to write a script which traverses *thousands* of machines to adjust text files. This task would be much, much harder with an API-based registry.
I commend the authors of the software for _wanting_ to make life easier for sys-admins of all stages. But I'm sorry guys, this does not _make_ it easier.