linuxbutler

It’s annoying to have to type file:///usr/share/doc/debian-policy/fhs/fhs-2.3.html when you want to see the File Hierarchy Standard … so I made a “desktop icon” pointing to several debian references. After way too much fishing around, I ended up doing the following on my xfce4-based desktop:

Why do I want to run a second X server on my desktop? So I can log in with another account without logging out of the first.

My ssl certificate expired the other day and I had to replace it.

Recently I recorded an episode for Hacker Public Radio. It answers some questions that another contributor, knox, had about virtualenvwrapper. My episode will (if all goes well) be published on June 27 as episode 2322.

I had a very smooth upgrade of a Debian wheezy system to Devuan jessie. This is a small system that doesn’t have a desktop or use any other dbus things — it mostly runs as an unattended server and I only connect to it occasionally.

Happy birthday Devuan!

Devuan is a systemd-less fork of Debian.

I’m lucky enough to be sitting in the netconf conference, with Pablo Ayuso, Jamal Hadi Salim, David Miller and others. They are discussing current and proposed future work on the networking subsystem of the Linux kernel.

This is the by-invitation-only mini-conference. Many of the attendees here will speak at the open-registration netdev01 conference from Feb 14 — 17 at the same venue (the Westin Hotel, downtown Ottawa). It’s looking like that conference will be really great. It’s not too late to sign up! I’ll definitely be there.

I looked up a question on stackoverflow, and even found it. But it had no answer, so I wrote one.

With luck, it’s not too far wrong.

… well I guess I answered the wrong question. Oops.

Can an existing folder be redeclared a virtual enviroment with VirtualEnvWrapper?

I thought this was a project that had been made with virtualenv, and they wanted to put it under virtualenvwrapper. But apparently it was made with virtualenvwrapper, and I don’t know what they want to do with it.

They can probably get the answer to their question from my answer, though.

My answer:

Yes.

Anatomy of virtualenvwrapper

The existing project has two parts:

• the virtualenv, where python and the python libs are installed, and
• the project directory where your code is (that uses the virtualenv).

Virtualenvwrapper adds a third part, the virtualenvwrapper hooks. These are mainly shell functions that are called at certain times in a project or virtualenvs life cycle. They live in a third directory — by default, they are installed to ~/.virtualenvs (at least that was true on my Debian wheezy system). The hooks include postactivate, which we will edit below, and a bunch of others such as premkproject, premkvirtualenv, etc. The following list of keywords gives you the flavour of the hooks: initialize, pre/post, mk/rm, project/virtualenv, activate/deactivate. virtualenvwrapper puts these scripts in $VIRTUALENVWRAPPER_HOOK_DIR, which defaults to $WORKON_HOME.

virtualenvwrapper assumes

• all the virtualenvs are in one place ($WORKON_HOME) (defaults to ~/.virtualenvs) Let’s say you have two virtualenvs, one called MYVENV and the other called MYOTHERVENV
• all the project directories are in another place ($PROJECT_HOME).

Let’s say you have a project “is” in directory /home/me/where/my/proj that uses virtualenv MYVENV.

how to use workon to work on your pre-existing code and virtualenv

Here I’m assuming all your virtualenvs are in one place (in my case, they are all in /usr/local/virtualenv).

one-time operations

** edit ~/.virtualenvs/postactivate (+) to have

    case $env_name in
        MYVENV)
            cd /home/me/where/my/proj/is
            ;;
        MYOTHERVENV)
            cd /home/me/where/my/other/project/is2
            ;;
    esac

** links

    for hk in get_env_details initialize postactivate postdeactivate \
            postmkproject postmkvirtualenv postrmproject \
            postrmvirtualenv preactivate predeactivate premkproject \
            premkvirtualenv prermproject prermvirtualenv; do \
        ln -s ~/.virtualenvs/$hk /usr/local/pythonenv/$hk; \
    done

any time you want to work on your project that uses MYVENV virtualenv

    WORKON_HOME=/usr/local/pythonenv workon MYVENV

Of course if all your virtualenvs are indeed in the same place, you can define WORKON_HOME in your .profile and you won’t have to specify it on the command line every time.

The problem I’m trying to solve here is to see if my web app is setting the right headers on the response. But, the web app is under https so it’s hard to sniff. Here’s how I did it. Hopefully next time I have to do this, I will find this hint and get going a lot quicker.

In the thing below, pretendhostname is a name that the remote web server uses for the server name, and the local machine has as an alias to 127.0.0.1. Also, I have used ssh port forwarding to send the data to the remote web server.

• In /etc/apache2/sites-enabled/the-web-app:

  <VirtualHost *:443>
      ServerName pretendhostname
     ...
  </VirtualHost>
  

• ~/.ssh/config stanza for some remote network on which the remote web server (10.0.0.26) runs:

  Host remote_gateway
          ...
          LocalForward 8443 10.0.0.26:443
  

• in /etc/hosts on my local machine:

  127.0.0.1       localhost pretendhostname
  

• Type these commands:

  $ ssh remote_gateway
  

  then in a different terminal on my local machine:

  $ curl -L -b cookie.data -c cookie.data \
      -d 'username=theusername&password=thepassword' \
      -k -D headers.txt \
      https://pretendhostname:8443/login/
  $ curl -L -b cookie.data -c cookie.data \
      -d 'username=theusername&password=thepassword' \
      -k -D headers.txt \
      https://pretendhostname:8443/some/path/somefile.data
  

This will put the headers of the response into headers.txt, where I can inspect them.