Search This Blog


Tuesday, September 22, 2015

Bash - Get output after matching line

$ cat file.txt
line 1
line 2
this is the line
line 4
line 5

If you want lines starting from "this is the line"

$ cat file.txt | awk '/this is the line/{ f=1; } f'
this is the line
line 4
line 5

When the line is found, set f to 1.
The last 'f' is shortcut to 'f == 1 { print }'

If you want output after the matching line

$ cat file.txt | awk '/this is the line/{ f=1; next; } f'
line 4
line 5

Saturday, August 01, 2015

Get celery init.d scripts

Downloads init.d scripts (celeryd and celerybeat) for your installed version.
Also accepts APP_NAME as an argument. Saves the files as celeryd-<app_name> and celerybeat-<app_name>

Install Redis inside virtualenv

Just run this script.
Puts the redis.conf in ${VIRTUAL_ENV}/etc/redis.conf.
Adds a wrapper redis-server-ve to use this conf by default.

Defaults to stable release. Else pass the version as an argument.

Monday, October 27, 2014

Packer vmware-iso on Ubuntu 14.04 with VMware Player 6

VMware build can be done with packer on Ubuntu using VMware Player 6.

Download VMware Player 6 from:|PLAYER-603|product_downloads

Also, click on Driver & Tools and download the correct version of VIX.

$ wget
$ chmod +x VMware-Player-6.0.3-1895310.x86_64.bundle
$ sudo ./VMware-Player-6.0.3-1895310.x86_64.bundle

$ wget
$ chmod +x VMware-VIX-1.13.3-1895310.x86_64.bundle
$ sudo ./VMware-VIX-1.13.3-1895310.x86_64.bundle

$ sudo apt-get install qemu-utils

$ packer build vmware.json

If you see errors like vmware or vmrun not in $PATH, VIX was not installed properly.

If you see errors like "specified version not found", incorrect version of VIX was installed.

If you see qemu related errors, qemu-utils was not installed.

vmware-iso only outputs the vmware instance as .vmx along with other files.

To export to ovf/ova format
$ ovftool appliance.vmx appliance.ovf
$ ovftool appliance.vmx appliance.ova

Thursday, July 18, 2013

VMware Fusion - Permissions on Shared Folders on Ubuntu

VMware Fusion provides a nice functionality of sharing folder from host (Mac OSX) to guest (Ubuntu). But then, it seems they are more focused on windows guests, because they screwup on file permissions of shared folders.

"ls -al /mnt/hgfs" will show 501 dialout as user and group, which is sure to cause permission issues on linux guest.

Update: Found a more persistent alternative
1. sudo vim /etc/vmware-tools/
2. Search for 'vmhgfs_mnt="/mnt/hgfs"'. After this line add: 'vmuser=${VMWARE_MNT_USER:-root}'
3. Then search for 'vmware_exec_selinux "mount -t vmhgfs .host:/ $vmhgfs_mnt"' and replace it with following section:
   uid=`id --user $vmuser`
   gid=`id --group $vmuser`
   vmware_exec_selinux "mount -t vmhgfs .host:/ $vmhgfs_mnt -o uid=$uid,gid=$gid"
4. sudo vim /etc/init/vmware-tools.conf
Before the "pre-start" and "post-stop" lines add:
env VMWARE_MNT_USER=[The guest user you want]
5. sudo reboot

NOTE: This will have to be redone when you update/ reinstall vmware-tools

To fix this:
ssh to your ubuntu.
run command "id". Make note of uid and gid.
"sudo vim /etc/mtab"
look for line ".host:/ /mnt/hgfs vmhgfs rw,ttl=1 0 0"
Duplicate the line and change it to ".host:/ /mnt/hgfs vmhgfs rw,ttl=1,uid=1000,gid=1000 0 0"
"sudo umount /mnt/hgfs"
"sudo mount /mnt/hgfs"

Now do a "ls -al /mnt/hgfs" to verify if correct username and group are shown.

Ideally, vmware fusion should be making this as transparent as possible. But then again, they don't care because they still don't have a real competition. Once, we do some real competitors, maybe then might start worrying about such minor but key items.

Currently, I spend more time trying to get it working than actually working on a VM. I am desperately looking for a better alternative.

This seems like a pretty neat fix. On the sharing screen, VMWare could add a simple textbox for user name and next time vmware tools are installed, use this value while generating the vmware-tools.conf file.

Not sure when VMWare will take note of such minor issues.

Tuesday, May 07, 2013

error in setup.cfg: command 'nosetests' has no such option 'with_pylons'

When running nosetests, if you see error in setup.cfg: command 'nosetests' has no such option 'with_pylons' or Error reading config file 'setup.cfg': no such option 'with-pylons', it could be because you have Pylons==1.0* installed. Pylons==1.0* does not register itself as a nose plugin ( Use following work arounds:
  1. For "python nosetests":
    Add the following to your projects " -> entry_points" and ".egg-info/entry_points.txt"
        pylons = pylons.test:PylonsPlugin
  2. For "nosetests --version":
    sudo vim `which nosetests`
    Make it look something like:
    # EASY-INSTALL-ENTRY-SCRIPT: 'nose==1.3.0','console_scripts','nosetests'
    __requires__ = 'nose==1.3.0'
    import sys
    from pkg_resources import load_entry_point
    addplugins = []
        import pylons
        if pylons.__version__[0] == '1':
            from pylons.test import PylonsPlugin
    except ImportError:
    if __name__ == '__main__':
            load_entry_point('nose==1.3.0', 'console_scripts', 'nosetests')(addplugins=addplugins)
    now you should be able to run it as nosetests --version

Friday, April 19, 2013

Working with multiple Python projects

While working with multiple Python projects, you might soon realize you need different versions of the same Py package or packages are conflicting between multiple projects.
VirtualEnv to your rescue.
But once you go through the docs, install and start using virtualenv, you might soon realize it is a little cumbersome.
  1. You need to provide the complete path where you want to save your virtualenv environment folder. virtualenv proj1 will just create the env in your current directory. If you are using a long path to store your envs, it might be a pain to put it in every-time.
  2. To activate an env, source <path-to-envs>/proj1/bin/activate
  3. To find all envs, you have to ls <path-to-envs>. But this works only if you have all yours envs in a single place.
Don't worry, VirtualEnvWrapper is here to help you.
Now you have a wrapper which provides you some shortcuts to the virtualenv commands. But it doesn't end there. VirtualEnvWrapper provides you with the an extension system.
ls $WORKON_HOME and you will find files starting with "post" and "pre". These are simple shell scripts. You can add your commands to these scripts and they will be everytime you run one of the commands.
It doesn't end there. You can also have separate extensions for each of your env. ls $WORKON_HOME/proj1/bin/ should show some similar files starting with "post" and "pre". For eg. To go to your source folder when you activate your env, just add "cd to "postactivate"
All said and done, one thing that might trouble you is figure out what packages are available in your current env?
Yolk will prove useful here. Remember, you can write extensions in wrapper. Just add pip install yolk to "$WORKON_HOME/postmkvirtualenv" and yolk will be installed on all new virtual envs created automatically. You can then activate your env and just use yolk -l to list packages available in that env.
Not much time for formatting. Will do it later.