Tag Archives: server

boa: Run a server from anywhere

Usually I steer away from server daemons on this site; I don’t have enough experience setting them up and the configuration can be a little tricky.

boa was fairly straightforward though, even when I added the complication of yanking the Debian binary and jamming it down the craw of my Arch installation.

2015-04-10-lr-0xtbe-boa

No major accomplishment in the grand scheme of things, but I at least have a real screenshot to show off. :\

Everything I know about boa is off the Debian page or the help flags, with a little more added in the configuration file. If you point everything at the current directory when boa runs, it will serve up its own folder, much like you see above.

On the one hand, that might be preferable to some of the complexities for members of the high-end server market.

Apparently boa runs on an exceptionally small amount of resources, and can even do its business on Pentium-grade equipment. I don’t have a Pentium machine now that I can put that claim to the test, but perhaps the next one that comes along, I’ll try. (Actually I do have one now, but it’s so badly battered that I’m considering setting it free.)

That’s about all I can say about boa, but that’s mostly because I’m fairly ignorant about web servers to start with. If you’re in that racket and need something with a smaller profile, boa might be for you.

In Debian. Not in Arch. πŸ˜‰

bitpocket: Your in-house drop box

I have three i686 machines at the moment, all three of which are running Arch. One acts as a wireless relay to the other two (thanks, create_ap), and shares its wired connection with the two others.

It also is set up to sync itself against the Arch repositories once a day, and then I manually rsync between the other two and share the downloaded updates. This saves me the drag of triple-updating machines, since my in-house wireless connection is considerably faster than the wired line.

Anything leftover or specific to one piece of hardware — like video drivers — gets downloaded normally, when a specific machine does its update.

I do end up doing some double-back synchronization, from satellite computers to the central hub. That’s more of an insurance measure or to make backups of individual packages that were downloaded to specific machines.

All that rsyncing back and forth relies on sshd of course, and it gets a little tedious having to re-enter passwords on every rsync, but I don’t know if there’s anything to be done about that. It’s the nature of the beast.

I thought perhaps working a little bit with bitpocket might give me some ideas, since bitpocket is intended as a do-it-yourself Dropbox-style network storage tool, built upon the mighty rsync.

2014-11-07-2sjx281-bitpocket

It did and it didn’t. bitpocket runs into much the same issue as I had, where I needed to supply a password four times — actually five — to get the proper access across the network and update the master folder on the central machine.

I don’t hold that out as a fault of bitpocket though, since whatever setting or configuration I’m after to solve my own problem isn’t bitpocket’s responsibility. I shall pursue that independently.

bitpocket itself is rather useful, and very easy to set up. Supply a proper folder and identity for your server machine, create a folder for a corresponding copy on the client, and just call bitpocket from that folder. bitpocket can check for updates, synchronize new files, delete old ones and generally handle everything as it should be done.

bitpocket has some other features that are nifty, such as the ability to tell you what will be updated (in other words, what changes exist since the last sync) and delete protection, where it moves “deleted” files into a hidden folder, in case you make a mistake.

If you already do fairly regular rsyncs against a master machine, or if you just want to streamline the process of keeping work folders up to date, I can see where bitpocket might improve upon a long chain of rsync commands.

In my case, I really need to find out how to authenticate rsync without being prompted each time, and follow through with that. (Edit: I figured it out, thanks. I just needed to generate an id_rsa.pub key, and move it over to the server. πŸ˜‰ )

ngincat: Four lines of bash, plus netcat

Sometimes I run across small feats of wizardry that don’t really impress much as a solid and whole application, but are worth mention anyway.

Lonnie sent a note about ngincat, a tiny http server written in bash around netcat.

2014-11-06-2sjx281-ngincat

It’s not bulletproof, it’s not secure and probably not a great idea outside your home network or maybe as an intra-office gizmo. But doggone it, that’s pretty darned cool for four lines of bash.

And in part it’s no surprise, since netcat is only the ultra-wickedest network tool out there, save maybe socat or nmap.

As for a true case use, I’ll see if I can combine this with vee, and end up with the leanest functional in-house blogging site known to man. And I’ll surf it with the world’s smallest graphical browser, just to be sassy. πŸ˜‰

xprobe2: What’s it running … probably?

I like tools like xprobe2. I don’t have any real reason to use them, but it’s fun to poke around and see what information is available.

2014-07-04-l3-b7175-xprobe2-01 2014-07-04-l3-b7175-xprobe2-02

xprobe2 supposedly polls a target server, and judging by its replies, makes an educated guess as to what operating system it’s using.

There are some other tools that do this too; supposedly nmap can handle this as one of the many things it has at its disposal. And I’m sure there are some other tools that start with N that can swing it. πŸ˜‰

Some problems: xprobe2 (I see there was an “xprobe1” project too) is quite a few years out of date for what I can tell. The last timestamp I see in the sourceforge collection is 2005, and I don’t know if changes in the operating system landscape have been reflected in xprobe2’s little digital mind. I have my doubts.

That might be why it thinks Google’s servers are running on Mac OS X. I guess that’s not impossible, and it might be that Google is deliberately confounding efforts like xprobe2. I trust the results from kernel.org a little more, although I don’t know if the site would rely on a backdated kernel … what with the NSA’s sudden emergence as the bad guy of the decade.

xprobe2 is in the Debian repos as just “xprobe,” and works fine. The AUR version, on the other hand, is well beyond its expiration date and will build a 0Kb package if you don’t wrangle with the PKGBUILD file first.

On top of that, the home page is a bit convoluted, and I seem to occasionally get twisted around and hit misdirected pages.

I mention all these things to highlight that, while it’s fun and a vaguely useful tool, I don’t know if I trust the output, I can see that the project is very much out of date, and I have a feeling some sites might be feeding it misinformation. So … use at your own risk. πŸ˜‰

ss: A quick dump of socket statistics

There’s a nifty little socket reader lumped in with iproute2, and if you didn’t think to look for it, you probably wouldn’t know it was there. Here’s ss:

2014-05-08-6m47421-ss

I’ve prodded ss a little more than is necessary there, just to keep the results on the screen and lined up neatly; that’s what head and column are for. ss will do that for you for free, but then the results wouldn’t make a good screenshot. πŸ™„

ss can read network or X server info; the man page lists quite a few options for each, as well as some examples to get you started.

ss will also allow you to filter stats by TCP states, match ports or addresses, and a slew of other nifty tricks. The man page compares ss to netstat; I’d probably lump them into the same category too, just out of naivetΓ©.

And yet strangely, I’ve not heard as much about ss. Perhaps this is another one of those Linux secrets I keep stumbling into. … 😐

sntop: A simple, network kind of top

For as many *top programs as there are, it shouldn’t surprise me that there’s an sntop. It should surprise me that sntop is a little … different.

2014-05-02-6m47421-sntop

sntop doesn’t really poll anything local, unless you tell it to test your loopback address. Otherwise, sntop checks servers — or other addresses, like a network access point — to see if they respond. Simple enough.

And in terms of setup and output, sntop is pretty simple too. It won’t do anything until you give it a proper ~/.sntoprc file, and configuration is very straightforward — a display name, its IP and a space for comments or notes. That’s about it.

Output, as you can see above, is also fairly simple. sntop will pause until you press a key, and then recheck every server in its list.

sntop can also dump to an HTML file, and has a few command line options as well. It can refresh at interval, sound an alarm if something isn’t responding, and output to a log file.

So yes, while it is simple, it can do a lot more than just what you see above.

siege: Hammer away at your server of choice

I like siege, even though it definitely falls into the bracket of “esoteric tools I will probably never have a use for.”

2014-04-25-6m47421-siege

siege attempts to burden a target server with a lot of traffic, ostensibly so the site designers and server administrators can see how well it stands up to the load.

I certainly have no problem with that, and as you can see above, apparently neither does Google. For the three seconds I pretended to be 10 people. 😐

siege is very easy to figure out; the man page takes all of about four minutes to read, and the options are very intuitive. You can follow my example above if you like, keeping in mind that without the -t flag, siege will run ad infinitum.

And it has color! πŸ˜€

siege is in Arch and Debian. I count siege as a useful and intuitive tool that’s worth exploring … but unfortunately, I’ll probably never need it personally. All the same, a big green smilie for siege: :mrgreen: