This entry will concern tunneling so as to get around port-blocking restrictions. It's something I learned about some years ago, but had a difficult time wrapping my head around it. While I can't say I understand it a whole lot better now, I can at least say that I've been able to get it working.
In my case it was needed because I've been working in a library whose wifi network is set up to block a variety of non-standard ports. That's a problem for me since I run my (command-line) e-mail client on a home computer, and I connect to that computer via ssh--which, in turn, runs on a non-standard port. So, when I work in this library, I am unable to connect to my home machine to do e-mailing. There are also occasional problems with sites being blocked on this network (and, no, I'm not rying to view porn).
For this to work, one must have access to some machine outside the wifi network that runs ssh on port 443. I happen to have a shell account with a service that has just such a set-up.
In my case, then, I can set up the tunnel as follows:
ssh -L localhost:1234:my.dyndns.url:12345 -p 443 my-user@my.shellacct.net.
I am asked for my password, then logged into my shell account, and the tunnel is thus opened.
Then, to connect to ssh as running on my home machine, I simply issue
ssh -p 1234
To get around the occasional page blocking I've run into, I first downloaded a browser I will dedicate to this task--namely, qupzilla. Then, I need to set up a socks proxy, which is done via ssh, like so:
ssh -D 8080 my-user@my.shellacct.net -p 443
After that, it's a matter of configuring qupzilla (or your preferred browser) to route web traffic over the socks proxy you've just created. That's done by going to Edit > Preferences > Proxy Configuration, ticking the Manual configuration radio button, selecting socks5 from the drop-down menu, then entering localhost into the first field next to that and 8080 in the Port field. Click Apply and Ok, and qupzilla will be set to route its traffic over your proxy, thus avoiding the blocks instituted by the wifi network.
With this basic information, it should be clear how other sorts of ssh tunnels and/or proxies could be set up.
Tuesday, November 18, 2014
Friday, July 18, 2014
Miscellaneous Friday quickies: The Plop boot manager; what is it and why would you need it?
Prefatory remark: I am uncertain of the licensing status of the project discussed in the posting below, but I suspect it may not--unlike most of the other utilities I discuss in this blog--be open-source.
Unless you, like me, are stubbornly trying to repurpose aging hardware, this tool might not be of much interest to you. But it allowed me to get an older machine booting from USB when BIOS limitations were interfering, , so I decided to document here the fairly simple procedures I followed to accomplish this in case they might be of benefit to others.
How old was said machine? Well, old enough to not only have problems booting from USB flash drives (BIOS USB boot options were limited to USB floppies or ZIP disks), but to have a floppy drive in it as well! A single core machine, as you might guess, although the motherboard did at least have SATA headers--which made it a good candidate for the project I had in mind.
I learned, through some on-line research, about the Plop boot manager--touted for enabling systems to boot from USB even where BIOS settings limited it--and that floppy disk images of the boot manager are included in the download. So I dug up and dusted off a floppy, downloaded the image, and wrote it to the floppy the GNU/Linux way--using dd:
dd if=/path/to/plpbt.img of=/dev/fd0
And that disk did, in fact, allow me to boot sanely from a USB thumb drive I'd plugged into the system. On boot, a starfield simulation reminiscent of the old Star Trek intro (ok, I'm dating myself here) appeared on the screen, in the foreground of which was a boot menu from which I could select the medium I wished to boot. And, sure enough, USB was one of the items.
That wasn't quite all I needed for my own application, however; you see, my hope was to have this machine run headless. So, how to make the boot manager default to booting from the USB drive after a certain number of seconds?
For that, it turns out, I needed another program included in the download called plpbtcfg. That program is what allows one to modify the binary file plpbt.bin. And plpbt.bin needs to be accessed somehow as well in order to modify it--accomplished in my case by mounting plpbt.img as a looped file system.
So I ran mount -o loop /path/to/plpbt.img /mnt/loop. Once that image had been thus mounted, I cd'd to where I'd downloaded plpbtcfg and ran plpcfgbt cnt=on cntval=4 dbt=usb /mnt/loop/plpbt.bin: that gave the boot menu a four-second time count, after which the computer would automatically boot from USB. I rewrote, using dd again, that image, to the floppy. So, mission accomplished.
Except some other aspects of that machine's operation proved not very suitable to the application I was hoping to deploy it for, so I'm not sure it will finally be put into service. But that's another story . . .
Unless you, like me, are stubbornly trying to repurpose aging hardware, this tool might not be of much interest to you. But it allowed me to get an older machine booting from USB when BIOS limitations were interfering, , so I decided to document here the fairly simple procedures I followed to accomplish this in case they might be of benefit to others.
How old was said machine? Well, old enough to not only have problems booting from USB flash drives (BIOS USB boot options were limited to USB floppies or ZIP disks), but to have a floppy drive in it as well! A single core machine, as you might guess, although the motherboard did at least have SATA headers--which made it a good candidate for the project I had in mind.
I learned, through some on-line research, about the Plop boot manager--touted for enabling systems to boot from USB even where BIOS settings limited it--and that floppy disk images of the boot manager are included in the download. So I dug up and dusted off a floppy, downloaded the image, and wrote it to the floppy the GNU/Linux way--using dd:
dd if=/path/to/plpbt.img of=/dev/fd0
And that disk did, in fact, allow me to boot sanely from a USB thumb drive I'd plugged into the system. On boot, a starfield simulation reminiscent of the old Star Trek intro (ok, I'm dating myself here) appeared on the screen, in the foreground of which was a boot menu from which I could select the medium I wished to boot. And, sure enough, USB was one of the items.
That wasn't quite all I needed for my own application, however; you see, my hope was to have this machine run headless. So, how to make the boot manager default to booting from the USB drive after a certain number of seconds?
For that, it turns out, I needed another program included in the download called plpbtcfg. That program is what allows one to modify the binary file plpbt.bin. And plpbt.bin needs to be accessed somehow as well in order to modify it--accomplished in my case by mounting plpbt.img as a looped file system.
So I ran mount -o loop /path/to/plpbt.img /mnt/loop. Once that image had been thus mounted, I cd'd to where I'd downloaded plpbtcfg and ran plpcfgbt cnt=on cntval=4 dbt=usb /mnt/loop/plpbt.bin: that gave the boot menu a four-second time count, after which the computer would automatically boot from USB. I rewrote, using dd again, that image, to the floppy. So, mission accomplished.
Except some other aspects of that machine's operation proved not very suitable to the application I was hoping to deploy it for, so I'm not sure it will finally be put into service. But that's another story . . .
Saturday, April 12, 2014
Miscellaneous Friday quickies: crop pdf margins with psnup
As sometimes happens, I recently needed to print off a portion of a public-domain work that's been scanned to portable document format and made available for download via Google Books. As the case proves to be at times, the original book had pages with fairly wide margins; when that sort of scanned book gets printed on letter-sized paper, you end up with a smallish text-box in the middle of a page that will have something like two-inch margins. That makes the text harder to read because the font ends up being relatively small, and it also results in waste of a lot of paper.
What to do, then, to make the text larger and make it occupy more of the page? I used three utilities for this job: xpdf to excise the target pages into a postscript file, psnup to enlarge the text and crop margins, and ps2pdf to convert the modified pages back to a pdf file. psnup is part of the psutils package, while ps2pdf relies on Ghostscript. A description of the steps I took follows.
With the pdf-viewer xpdf, the print dialog offer two option: print the document to a physical printer, or print to a postscript file. Both options allow for page-range stipulation. That's how I created a postscript file from the target pages.
Next, psnup--a really handy tool I've used previously for creating booklets (more about that in a future entry), but which I'd never considered might perform a job like this--was used to reduce margins, which had the added effect of increasing the text size. The command I used, which I appropriated from here, looks like this:
psnup -1 -b-200 infile.ps file_zoomed.ps
The crucial switch here seems to be -b (which is short for borders) followed by a negative numeral. Of course the numeral 200 as seen in this example will need to be modified to suit your circumstances.
The final step of converting file_zoomed.ps, using ps2pdf, to a pdf was simplest of all--in fact so simple that I won't even describe it here. I hope this brief description may be an aid to others wishing to execute a task like this.
Finally, I ran across some other related information of interest while reaserching how to crop pdf margins. Here, for example, is a page that describes a few other, more technically-involved ways to reduce margins: http://ma.juii.net/blog/scale-page-content-of-pdf-files. This posting on the Ubuntu forums has a really interesting script someone put together for making pdf booklets: http://ubuntuforums.org/showthread.php?t=1148764. And this one offers some clever tips on using another psutils utility--psbook--for making booklets: http://www.peppertop.com/blog/?p=35. Then, there's what might be the most straightforward utility of all for cropping pdf margins--pdfcrop. Since I could not get it to work for me in this instance, I looked for and found the alternative described above.
MUCH LATER EDIT: having done some further experimentation with pdfcrop I've discovered an important element: using negative values to specify width of margins. Doing this, I was able, using this tool, to trim margins to my staisfaction. A command such as pdfcrop --margins '-5 -25 -5 -40' MyDoc.pdf MyDoc-cropped.pdf ended up doing the trick for me quite nicely
What to do, then, to make the text larger and make it occupy more of the page? I used three utilities for this job: xpdf to excise the target pages into a postscript file, psnup to enlarge the text and crop margins, and ps2pdf to convert the modified pages back to a pdf file. psnup is part of the psutils package, while ps2pdf relies on Ghostscript. A description of the steps I took follows.
With the pdf-viewer xpdf, the print dialog offer two option: print the document to a physical printer, or print to a postscript file. Both options allow for page-range stipulation. That's how I created a postscript file from the target pages.
Next, psnup--a really handy tool I've used previously for creating booklets (more about that in a future entry), but which I'd never considered might perform a job like this--was used to reduce margins, which had the added effect of increasing the text size. The command I used, which I appropriated from here, looks like this:
psnup -1 -b-200 infile.ps file_zoomed.ps
The crucial switch here seems to be -b (which is short for borders) followed by a negative numeral. Of course the numeral 200 as seen in this example will need to be modified to suit your circumstances.
The final step of converting file_zoomed.ps, using ps2pdf, to a pdf was simplest of all--in fact so simple that I won't even describe it here. I hope this brief description may be an aid to others wishing to execute a task like this.
Finally, I ran across some other related information of interest while reaserching how to crop pdf margins. Here, for example, is a page that describes a few other, more technically-involved ways to reduce margins: http://ma.juii.net/blog/scale-page-content-of-pdf-files. This posting on the Ubuntu forums has a really interesting script someone put together for making pdf booklets: http://ubuntuforums.org/showthread.php?t=1148764. And this one offers some clever tips on using another psutils utility--psbook--for making booklets: http://www.peppertop.com/blog/?p=35. Then, there's what might be the most straightforward utility of all for cropping pdf margins--pdfcrop. Since I could not get it to work for me in this instance, I looked for and found the alternative described above.
MUCH LATER EDIT: having done some further experimentation with pdfcrop I've discovered an important element: using negative values to specify width of margins. Doing this, I was able, using this tool, to trim margins to my staisfaction. A command such as pdfcrop --margins '-5 -25 -5 -40' MyDoc.pdf MyDoc-cropped.pdf ended up doing the trick for me quite nicely
Monday, March 17, 2014
Miscellaneous Monday quickies: volume adjustment via keyboard
Being an enthusiast of minimalist GUI systems, I'd heard some time ago of the i3 window manager and liked what I'd read. Recently, I switched over a couple of my computers to it and have been quite happy with it.
I ran across a news item the other day that was touting the virtues of i3 and which therefore caught my interest. Especially intriguing was the author's description of how, using that WM, certain keyboard keys or key combinations could be mapped so as to govern the computer's sound ouput--intriguing, that is, even apart from the fact that it was a description of a system configured to use pulse audio for sound output (my preference for ALSA over pulse is material for another entry). Still, I felt it should not be too hard to modify those directions to suit my systems.
As in the article referenced, it was a simple matter of modifying ~/.i3/config, adding some lines. In my case, the lines were as follows:
The keyboard on that particular machine is what I believe is called a "multimedia keyboard," meaning that it has a few keys dedicated, rather than to alphanumeric characters, to multimedia functions such as volume control. Finding which key codes to place in that file was a simple matter of using the xev utility. The ALSA--as opposed to pulse audio-- commands for raising, lowering, and muting volume were readily found in an internet search.
After a few trial runs and further tweaks, a quick restart of i3 revealed that things were working as expected. Flush with success from that project, I decided I might get the same thing working on another computer in my apartment--though that computer, since it needs to be usable for my wife, runs a different WM; incidentally, it runs JWM with a home-brewed Gnome 2 mock-up interface (I plan to do a write-up someday describing the Gnome 2 mock-up I created).
The basic idea of getting keyboard keys controlling volume is the same, though it involves editing a different configuration file--named ~/.jwmrc--that uses alternate syntax. Since the keyboard attched to this machine is not a multimedia keybaord, I ended up repurposing some seldom-used keys, in combination with the Alt key, for volume control functions. The entries in that file are as follows:
That pretty much sums it up this quickie entry.
I ran across a news item the other day that was touting the virtues of i3 and which therefore caught my interest. Especially intriguing was the author's description of how, using that WM, certain keyboard keys or key combinations could be mapped so as to govern the computer's sound ouput--intriguing, that is, even apart from the fact that it was a description of a system configured to use pulse audio for sound output (my preference for ALSA over pulse is material for another entry). Still, I felt it should not be too hard to modify those directions to suit my systems.
As in the article referenced, it was a simple matter of modifying ~/.i3/config, adding some lines. In my case, the lines were as follows:
The keyboard on that particular machine is what I believe is called a "multimedia keyboard," meaning that it has a few keys dedicated, rather than to alphanumeric characters, to multimedia functions such as volume control. Finding which key codes to place in that file was a simple matter of using the xev utility. The ALSA--as opposed to pulse audio-- commands for raising, lowering, and muting volume were readily found in an internet search.
After a few trial runs and further tweaks, a quick restart of i3 revealed that things were working as expected. Flush with success from that project, I decided I might get the same thing working on another computer in my apartment--though that computer, since it needs to be usable for my wife, runs a different WM; incidentally, it runs JWM with a home-brewed Gnome 2 mock-up interface (I plan to do a write-up someday describing the Gnome 2 mock-up I created).
The basic idea of getting keyboard keys controlling volume is the same, though it involves editing a different configuration file--named ~/.jwmrc--that uses alternate syntax. Since the keyboard attched to this machine is not a multimedia keybaord, I ended up repurposing some seldom-used keys, in combination with the Alt key, for volume control functions. The entries in that file are as follows:
That pretty much sums it up this quickie entry.
Saturday, March 8, 2014
Miscellaneous Saturday quickies: udev rules and you
PREFACE: "udev is a device manager for the Linux kernel. Primarily, it manages device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware loading." (Wikipedia entry for udev) Those wanting a better orientation to udev may wish to do some further reading of material found at some of the links provided in this entry.I felt a great sense of triumph when, oh, 5 or 6 years ago, I managed to create a udev rule that would make a scanner I was trying to use be identified in a certain way to the system. In the wake of that project I was also able to craft some udev rules for some external hard drives I was using. Since then, I've learned, however, that computer tech is a quickly moving target; the things I took such great pains to learn and apply back then, as I now know, might be of little use to me in just a few short years.
Case in point: fast forward to yesterday, when, after a Mythtv/Mythbuntu upgrade, one of the capture cards I'd written a udev rule for was no longer being properly identified to the system. The reason being, of course, that some changes had been made to udev conventions and the old trick I'd used to identify that card to the system was no longer working.
So I had to rewrite the rule. It turns out some parts of the routine for identifying and naming devices have been a bit simplified. The new incantation I needed to run to find out details about the catpure card which I could incorporate into the udev rule goes like this:
(where sdb is replaced by the device name of the hardware you're querying--in my case, video0)
That bit was lifted from a 2009 entry from a blog located here. He references an even older web page as a source for his information, one I'd used in my first attempts 5 or 6 years ago, and which looks to be pretty outdated now. That page is called "recativated" and can be found here.
In any case, an even simpler rendition of the incanation above is offered in the "comments" section of that blog, as follows:
Both gave the results I needed and helped me resolve the issue of the card being identified and labelled as I wanted it to be. Maybe this information will be useful to you as well--at least so long as you find and try to apply it before the next big change comes to udev, or udev gets superseeded by some other, "better" utility.
Subscribe to:
Posts (Atom)