sshrc: Piggyback your rc across ssh

I just got a message about sshrc a few weeks ago, but I didn’t make a note of who sent it. 😦 So if it was you, I apologize; I do like to give credit to the discoverers whenever possible.

sshrc allows you to inject your own set of aliases, functions, environment variables and so forth into a remote ssh session. This might be preferable to following the conventions of the host machine, particularly if you’re used to a specific command or alias.

And as you can see, it works quite well. sshrc keeps its own configuration file, so you don’t have to make any changes to your local .bashrc or .bash_profile to use it.

According to the home page, sshrc can also piggyback special files or scripts in your ssh journeys, such as vim configurations or other specialized rc files. That might sound somewhat dangerous, as if it could potentially overwrite distant files.

But the home page promises they’ll be kept out of harm’s way and in a unique location that won’t taint any other configuration files. I leave it to you to decide if that’s the case.

sshrc is another of those programs that I wish I had more call to use. As it is, I keep mostly the same configuration across all the machines I have right now, and it’s a very rare case that I have something special on one machine that I don’t have on another.

I can see where sshrc would be useful though. I plan to keep this in the back of my mind, should the need ever arise. 😉

stow: Not just for package management any more

GNU stow is another one of those projects that took me a while to wrap my head around, but once I saw it in action, it made perfect sense. Of course, given that stow doesn’t really show any output, that statement is ironic on another level.

As I understand it, stow is intended as a kind of package manager for software you might build locally — which in my case, is quite a lot. stow works by creating symlinks from a program’s original location to a central depot of your creation.

The idea is that this reduces the chances of unforeseen conflicts, and makes managing random, scattered files easier, since most everything is in the same place. One program, one folder, and appropriate symlinks elsewhere in the system.

If that doesn’t make a lot of sense, don’t worry, because two hours before I wrote this, I was trying to wrap my head around it too. Now though, I think I see the value in it.

What clued me in was this post by Brandon Invergo, where he talks about creating a folder specifically for dotfiles with stow. Brandon is an easy read and he gives you a good visual illustration, so don’t worry if you’re not a fan of reading from blogs. Neither am I (ironic, isn’t it?).

If you step through his post, you’ll end up with a small tree of folders with the dotfiles of each program nested individually. Your home folder will still hold links to those files, and everything will still work as it should. So don’t panic. 😉

I tested it with two programs that I thought more or less bulletproof, even if my configurations were utterly vaporized: htop and snownews. And after Brandon’s instructions, wouldn’t you know it, everything worked fine.

Why would I want to do this? Well, like Brandon explains, this makes it much cleaner to synchronize your dotfiles against an online repository — for example, you can more conveniently dump your dotfiles on github. No more cherrypicking files and sending them singly.

But personally, I usually have a lump of folders and settings that I transfer between machines, to expedite setup or testing. Even just in the past two or three days, I’ve ended up manually copying files from one machine to another, and from that machine to a third. In the future, I expect I can install stow, rsync the dotfiles folder to the new machine and jump right in.

I suppose you could do this manually, file by file and link by link, and not need stow. But just thinking about that should make it obvious why stow is a good tool: Manually setting up all those links would be tedious to say the least.

I have the reassurance of Brandon and some other sites that even if you uninstall stow, your link systems will continue to work. That makes sense to me, even if I haven’t taken that step yet.

stow has the potential to be a game changer for you, if you need that kind of added flexibility with packages or with your personal configuration files. It won’t clean up your home directory — you’ll end up with just as many symlinks as you had configuration files, and in the same place — but it adds a layer of convenience that you might find immediately attractive.

dotbot: A (dot)files (bo)o(t)strapper

Something else you might have noticed: I’m not following alphabetical order any more. 😉

I started doing that about a year ago, because I was conveniently skipping titles I didn’t know anything about or sensed were over my head.

Scraping through the alphabet was a way of making sure I at least mentioned each title before moving to the next one. The way things were going, I would have ended up with a list of software I had no interest in, and no desire to examine.

So at the moment, it’s a simple ls vimwiki/ | shuf -n1 that determines the next title. This will also keep you guessing, so you never know how close we are to The Real End of The List. 😉

However I do it, I still see titles that I’m unlikely to adopt, sometimes for personal reasons.

Next is Anish Athalye‘s dotbot, a tool specifically designed to handle dotfiles symlinked against github. I’ve seen people do this in the past, or use github as a repository for their dotfiles.

I’m a little timid about that though. Call me old-fashioned, but I still find The Cloud to be a little sketchy. I always have. Plus, I have used some real maverick software in the past, that stores passwords in plain text in dotfiles. 😯

Of course, my sense of dread stems from the downward turn of online privacy in recent years. But it also plays havoc with my less-than-stellar link to the Internet. When you realize you have a fragile connection, you adjust your lifestyle accordingly.

Anish promises that dotbot is easy to set up and for what I saw, it was. I don’t have a screenshot this time, and I apologize for that.

At the time of this writing, dotbot had seen attention within the last month. Like I mentioned earlier, a lot of the upcoming programs are worth mentioning because they’re more active; dotbot is a good example of that.

If you give dotbot a whirl, and it suits your fancy without triggering alarm bells, please use it with my blessing. Send along a screenshot if you like. 😉 Just because I steer away from a program doesn’t mean everyone else should. You are your own person. Stand your ground. Hold your head up.

Go forth, and preach the gospel of dotbot. 😀

iptstate: Top, for iptables

Once you get iptables working, you’ll probably want iptstate next.

As I understand it — and again, networking is not my strong point — iptstate lets you watch traffic as it crosses iptables, and sort or filter it, like top does. And atop, and powertop, and iotop and. … 😯

 

I can’t show a whole lot for it, mostly because I don’t have iptables configured right now. The home page has better screenshots of how it looks in action.

I can see where this would be useful, provided it was configured and running properly. And I imagine in a complex network environment, it would be quite impressive to watch.

Of course, I’m a sucker for anything that manages the screen real estate and flashes a little color. 🙄

iptables: It’s better if I don’t explain

I thought perhaps, a month or so ago, that I would walk through iptables slowly and carefully, since it’s a tool that’s very useful and in just about every distro.

But as seems to be the case these days, I keep finding better explanations already published on the ‘net, by people with much more experience than me.

Times like this reinforce the need not to repeat information endlessly, especially when — to be honest — networking and firewalls are not my strongest points. 😕

So what I’ll do is give a few links to the better tutorials that I found, and not waste anyone’s time by polluting the Internet with repeated information.

Listed not in any particular order:

• The Arch and CentOS wikis, which are good starting ponts;
• The Geek Stuff, which does a good job adding a visual element to the explanation;
• and finally, the LinuxJournal video series, for those who prefer to hear and watch, instead of read.

Sorry if this looks like a cop-out, but what I realized after starting my own weak-sauce “tutorial,” was that many other people had already done it, and much better. 😐