Contents

Firefox script to open in new window, new tab and open local files

I have created script that extends original firefox script with a few options. Running the script will handle the situation when firefox is called when another firefox is running, and pass the URL to the old one.
Moreover it adds switch, so you can select if the url passed will be opened in new window, new tab, or let firefox decide. Also it will allow passing local files (relative too), that will be correctly prefixed with file:// and path, and passed to firefox. From script help: 
firefox [ -t | -n ] [ URL | PATH ] ...
Options:
  -t                    open in new tab
  -n                    open in new window
  none                  open in same or new tab/window depending on user setting s
  URL                   open URL
  PATH                  open PATH (can be relative)
  none                  open new firefox default page or blank page (tab)

If there is no firefox running, it will be started

Examples:
  firefox -t            open new blank tab
  firefox -n URL        open URL in new window
  firefox -t image.jpg  open image.jpg from current directory in new tab
  firefox subdir        open subdir of current directory
  firefox .             open current directory
  firefox -n URL URL    open URL in new window and following ones in new tabs
Download: firefox-wrapper-1.1.tar.gz
You will need to hand edit the script to enter path to the original firefox. You can check it with whereis firefox or type firefox command. Usually it will be /usr/bin/firefox.
Also you should put that script on a search path so it is executed before orignial firefox, or always use full path to execute it. For example you can copy the file to /usr/local/bin, and add /usr/local/bin to the search path (if not there already, see 'echo $PATH' and /etc/profile).

Use files from other machine using NFS

Sometimes you need to setup "on demand" connection to access files on other machine. Situations I find it useful:
Sharing yum cache (1GB+ of already downloaded updates) with laptop that needs to be updated as well.
Normally laptop update would make it to redownload most of the files. Mounting /var/cache/yum in read-write mode from main computer on laptop's /var/cache/yum will save a few hours.
  1. Make sure that your /etc/hosts.allow includes your LAN in allow section. Important: following setup is security risk. Don't use it in untrusted environment.
    edit /etc/hosts.allow
    rpcbind : 10.1.0.0/255.255.255.0 : allow
    rpcbind : ALL : deny
  2. Export filesystem on server. Assume that your LAN is in 10.1.0.0/255.255.255.0 range. Actual values can be found in ifconfig command output (addr/mask).
    on server root console
    service portmap start
    service nfs start
    exportfs 10.1.0.0/255.255.255.0:/var/cache/yum -o rw,no_root_squash
  3. Mount the share on the client. Assume that server's IP is 10.1.0.1.
    on client root console
    service portmap start
    mount 10.1.0.1:/var/cache/yum /var/cache/yum -o nfsvers=2,rw
  4. To make such setup permanent, add portmap and nfs to services that startup at boot, edit /etc/exports on server and /etc/fstab on client. Remember that you are giving write access (also as root what is extremely dangerous) to anybody that can connect to your LAN (10.1.0.0/255.255.255.0).

Troubleshooting — mount: ... failed, reason given by server: Permission denied

  • Not sure since what kernel, but you need to mount nfsd virtual file system on server. Otherwise you will get:
    mount: 10.1.0.1:/var/cache/yum failed, reason given by server: Permission denied
    To resolve it type:
    on server root console
    mount -t nfsd none /proc/fs/nfsd
    You can safely make that permanent (automount on boot):
    edit /etc/fstab and add following line
    none /proc/fs/nfsd nfsd defaults 0 0
    It took me a few hours to resolve this issue... There are so many questions about above Permission denied message over the Internet, but I didn't find single answer with this hint...

    More troubleshooting


    More resources: sharing between SELinux Fedora Core and non-SELinux system

    Forward email as an attachment in pine

    By default pine attaches forwarded messages inline.
    Here is trick to forward email as an attachement.
    It is sometimes important that you preserve original headers when forwarding email. Eg., if you want to report spam.
    Forwarding as attachement do preserve email headers, attachement inline does not.

    Instruction:
    1. Open (or put cursor on) message you want to forward
    2. Enter Full Headers mode¹ (press h)
    3. Forward the mail (press f)
    4. Accept 'Forward message as an attachment?' (press y)

    Tested on pine 4.62. Is there any simple method? What displaying full headers has to do?

    ¹To be able to enter Full Headers mode, you may need to enable it in configuration:
    On main screen enter Setup (press s), Config (c), and check (x) enable-full-header-cmd in Advanced Command Preferences. Exit and save (e, y).

    WindowMaker DockApp does not show, or show in regular window

    Normally DockApps should be displayed in special mode, so they can be docked in one of screen corners. They also does not have titlebar, and does not require to be placed manually (if this is set up in Window Maker).

    Some old DockApp applications are somehow incopmatible with recent WindowMaker (tested on 0.91+), and either does not display at all, or display in regular "window".

    I didn't see confirmation of that behavior, so maybe this is only my issue (but on a few machines)m but solution I found is to modify the source code and change one line of code. Search for res_class string in the source and change right side of the expression to the "DockApp". Recompile.

    Old code
    something.res_class = anything;
    New code
    something.res_class = "DockApp";

    mplayer

    play DVD from file stored on a hard drive

    mplayer dvd://1 -dvd-device /tmp/movie-image.iso

    ZIP unsupported compression method 99

    Some password protected ZIP files, usually created with a recent WinZip (9.0 or newer), are encrypted using new method, the AES encryption.

    Older utilities like unzip on Linux, old WinZip, or pkunzip does not know how to handle that, and usually just abort operation complainting that they does not support compression method 99.

    To extract those ZIP files one can use:
    The 7z can be obtained from the 7z home site, but for Linux should be easily available from the system repository.
    Command line syntax for extracting the archive is: 7z x file.zip

    Very slow or dying Internet connection to some hosts

    I you have very slow (or quicky dying) connection to selected hosts and they work normally from other machines/systems you may be experiencing broken TCP window scalling on a host that is on the route between you and the target machine.

    The slow connection often gets noticed after recent system/kernel upgrade, or after adding more RAM to the system.

    Problem is that Linux kernel's window scalling paramters depends on the amount of system RAM, and other factors, so while old system could keep the TCP window size small, new may grow it more (i.e. for overseas connection), and broken boxes that mishandle window scalling parameter, effectively blocks the connection with large TCP window size. Notice that window scalling parameter changes during the TCP transfer, thus connection can start well, and got broken after some time.

    To check if your connection is affected by this problem you can temporarily diable window scalling with:
    as root:
    echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

    Another proposed workaround is to limit maximal window size with:
    as root:
    echo 4096 16384 131072 > /proc/sys/net/ipv4/tcp_wmem
    echo 4096 87380 174760 > /proc/sys/net/ipv4/tcp_rmem

    It is also possible to make these limitations only for a selected broken route (not to limit connection performance for entry system):
    There are black box devices out there, routers and firewalls and whatnot, that simply cannot grok the TCP window scaling option correctly.

    People should and do bark at the site running the device causing the problems, but in the mean time folks do want a way to deal with the problem. We don't want them to turn off window scaling completely as that hurts performance of connections that would run just fine with window scaling enabled.

    So give a way to do this on a per-route basis by limiting the window scaling by the per-connection window clamp. Stephen's changelog message explains how to do this using a route metric.
    [...]
    as root:
    ip route add 195.1.2.0/24 via 128.4.5.254 window 65535

    You can make any of these workarounds permanent, by adding those lines to your /etc/rc.local file.

    Lierature:

    Support for new version of IOGear GWU513 usb wireless card

    IOGear 802.11g WiFi card happens in two flavours. Earlier version (I'll call it v1) has ISL3880 chip and is fully¹ supported by recent kernels (2.6.24.3 at least). Later version (v2) has GW3887 chip and would (will) be supported by the vanillia kernel¹, but its id is not added to the driver configuration.

    To check if you have older or newer card you can use lsusb command. 124A:4023 is v1, while 124a:4025 is newer v2.

    ¹ Kernel driver to run needs external firmware called SoftMAC that is available from Prism Firmwares site. More information can be also obtained at http://prism54.org/ (except that as of now neither mention newer GWU 513 card).

    So to make v2 GWU513 card work, you need to:
    1. patch the kernel with add a 124a:4025 id patch and recompile it
    2. download the "Second generation device" firmware 2.5.8.0 (for v1 it would be "First generation device", 2.4.3.0)
    3. put it in appropriate place at appriopriate name in the system (on mine Fedora 8 it is /lib/firmware/isl3887usb_bare)
    4. load/reload p54usb kernel module (i.e. rmmod p54usb; modprobe p54usb)
    5. iwconfig should show the new card


    → Go back to Linux resources page

    Jan Słupski, email: jslupski at juljas dot net