Thursday, March 3, 2016

Copying with tmux and vim on Fedora 23

I use tmux and vim on Fedora 23. When I have vertically split windows, selecting with my mouse cursor selects across multiple open files. Today I finally got unlazy and googled around enough to figure out how to get text into my system's clipboard (since vim uses it's own paste buffer) from vim.

I used
Conner's answer here: http://stackoverflow.com/questions/11489428/how-to-make-vim-paste-from-and-copy-to-systems-clipboard and Ignacio Vazquez-Abrams's answer here:
http://superuser.com/questions/194747/how-to-install-vim-with-clipboard-support-on-fedora
to get copy/paste working for me.
  1. install gvim
  2. create an alias in my .bashrc file so I don't have to type 'gvim -v' instead of 'vi'
  3. To select:
    1. position your cursor at the beginning of the text block you want to copy
    2. shift+v ('V')
    3. arrow down
    4. "yank" the text using "+y (keydown shift ' and +, then keyup shift, then y)
    5. Paste into a different program (like gedit, which I use as a scratch-pad) using your mouse wheel or ctrl+v
Pasting is easy.

If you're new to vim, use :paste before pasting in code-blocks to preserve formatting.


Thursday, January 21, 2016

My Vagrant How-To (with libvirt)

I am super late the the Vagrant party. "All you have to do is vagrant up!" is all I hear from developers everywhere. But when I tried it, that was not my experience.

A lot of my life over the past several years has revolved around Linux and libvirt. I even did some backend work for a virtualization management platform called Kimchi. But since I was coming from the land of, "Here's your image, and here's your VM," I over-complicated it. "Where is the image I just downloaded?" "Doesn't my Vagrantfile need to be in the same place as that image?" The answers: "Don't worry about it," and "No."

So here's what I think is a pretty good explanation for people who are used to something like virt-manager but want to use Vagrant.

Intro: Projects, Vagrantfiles, & Boxes


Set up a directory to house your projects. You could source-control it, too. Then make subdirectories for each project:

$ mkdir vagrantfiles && cd vagrantfiles
$ mkdir someproject && cd someproject

This is before you've added any boxes. The directories will hold your `Vagrantfile`s – not your boxes. The base boxes (or .img files) live in ~/.vagrant.d/boxes, and are base images. When you set up a project, you'll be building on top of that base image. This allows sharing of one base image across multiple projects. So, pick a base you'd like to use a lot, and you'll save space on your hardrive.

Decide which box you want. You can look at available boxes from hashicorp here: https://atlas.hashicorp.com/boxes/search. Clicking on a box will show you more useful info, like the init command to use to get that box.

I want to use Fedora and libvirt (see Vagrant with Libvirt (on Fedora)), so I'm looking at https://atlas.hashicorp.com/fedora/boxes/23-cloud-base.  Let's init our project:

$ vagrant init fedora/23-cloud-base

If this is the first time you've used this box, it will download the base image. When it completes, you'll see a Vagrantfile in your directory.  If you want to do additional config, change your Vagrantfile first. The default one will get you a working VM with host networking, so that's good enough for me.

Now, up your box:
$ vagrant up --provider libvirt               # watch the config & start
$ sudo virsh list –all                               # see that your box is now running
$ vagrant ssh                                         # access your machine

For more, definitely read the Vagrant docs: https://www.vagrantup.com/docs/getting-started

Vagrant with Libvirt (on Fedora)

Installing the Plugin

There is a project to use libvirt instead of the default (Virtualbox) with Vagrant: https://github.com/pradels/vagrant-libvirt. The project instructions say to use the vagrant command to install the libvirt plugin. However, for Fedora at least, you should use dnf to install the plugin:

$ dnf install vagrant-libvirt

Box Configuration

As opposed to the Virtualbox provider, if you want to update some VM properties (e.g. VCPUs or memory), you'll need to use virsh (read: do it outside of Vagrant).

The default memory is 512M, which isn't going to cut it for my purposes. so I've gone back and updated my VM. In the future, I'll remember to add the following to my Vagrantfile *before* I 'vagrant up.'

config.vm.provider :libvirt do |libvirt|   
      libvirt.memory = 2048
end

Thursday, September 3, 2015

Docker SELinux Policy Revisited

This is a follow-up after my last post about pulling an selinux policy out of an rpm. It turns out, there's a policy in Docker's github at https://github.com/docker/docker/tree/master/contrib/docker-engine-selinux. Way! (Yes, that's a Wayne's World reference.)

So now I'm testing that out, to see if it gets me around the goroutine hangs (which then panic) I'm seeing if I have SELinux enabled/enforcing when I run the tests using gccgo (in my x86_64 Fedora 22 env).

To use:
# yum install selinux-policy-devel
# cd /path/to/local/docker/docker/tree/master/contrib/docker-engine-selinux
# make -f /path/to/local/docker/docker/tree/master/contrib/docker-engine-selinux/Makefile docker.pp
# sudo semodule -i docker.pp

But, I'm hitting https://bugzilla.redhat.com/show_bug.cgi?id=1177994, so that is a bummer. It took hours for the semodule command to finally fail, and my CPU was pegged at 99% until it finally return the error:

libsepol.check_assertion_helper: neverallow violated by allow restorecond_t semanage_store_t:file { relabelto };
libsemanage.semanage_expand_sandbox: Expand module failed
semodule:  Failed!

Update: I added the rawhide repo, updated libsepol & selinux-policy, and the semodule command completed.

Thursday, August 20, 2015

Getting an [un]official docker selinux policy for ppc64le

I've had all kinds of fun (yah, that's the word) with selinux and docker since I started working with docker back in March. My work laptop runs Fedora and I keep it at the latest supported release, so I've run into relabeling issues (https://github.com/docker/machine/issues/812) and others while building & running docker & docker-machine from upstream.

Recently I've been working on getting docker running on ppc64le. One of the things (because I'm a crazy stubborn person?) I refuse to do is disable selinux. Since RHEL doesn't ship docker for ppc64le, it doesn't ship an selinux policy for docker on ppc64le.

Option #1: Run audit2allow and create a policy.
Option #2: Use the docker policy that RedHat ships in an x86 rpm.

I am still learning how to safely generate my own selinux policies, so for now, I'm trying out #2.

Note that I'm using the newest policy available, which is for docker 1.7.1. Since I'm building from upstream, right now I'm running with docker 1.9 and hoping that docker doesn't want any new capabilities since this policy was written.

fc22-x86> rpm2cpio docker-selinux-1.7.1-108.el7.x86_64.rpm | cpio -id
fc22-x86> cd usr/share/selinux/packages/
fc22-x86> bunzip2 docker.pp.bz2
fc22-x86> scp docker.pp user@rhel-system:/home/user/location/.

rhel-ppc64le$ sudo semodule -i docker.pp



Now my docker tests are running. If they don't finish for selinux reasons, I'll post updates.

Update: When running with gccgo, I was getting goroutine hang/panics, and my tests weren't finishing. I happened upon a policy file in docker's github! See my newer blog post on this.


Tuesday, July 21, 2015

More VM Partition Fun

Docker images live in /var/lib/docker, so it's a good idea to set up a large /var if you're going to run docker. Otherwise, you get a large /home by default on some installs (like RHEL7).

A text-based install doesn't allow you to customize your partitions,, but a GUI install is a PITA to do on a VM in a lab on a slow private network that you're VPN'ing into, so just take the std LVM setup and then change it after installing:

- resize (shrink):

   --- Logical volume ---
  LV Path                /dev/rhel-l/home
  LV Name                home
  VG Name                rhel-l
  LV UUID                tXagVh-QH6i-smrg-Vt7h-y0cX-IenE-oitcIx
  LV Write Access        read/write
  LV Creation host, time localhost.localdomain, 2015-07-20 15:13:46 -0500
  Current LE             39793
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:2

# lvresize /dev/rhel-l/home -L 55G

==
- make var:

lvcreate -a -n var -L 100G rhel-l

  --- Logical volume ---
  LV Path                /dev/rhel-l/var
  LV Name                var
  VG Name                rhel-l
  LV UUID                57vY5M-3Mq6-0z70-WlWI-wcjd-BJpU-UTeP8v
  LV Write Access        read/write
  LV Creation host, time rhel7-1-ci-ppc64, 2015-07-20 15:31:02 -0500
  LV Status              available
  # open                 0
  LV Size                100.00 GiB
  Current LE             25600
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:3

==

- mkfs -t xfs (since RHEL 7) on both /dev/mapper/ ... var and ... home
- update /etc/fstab (add line for /var)
- mount -a   

==

Thursday, July 9, 2015

My first tech blog post: Resizing a VM disk image [cheat sheet]

Much akin to my painful decision to buy a smartphone because I couldn't remember appointments I'd made, I'm deciding today to enter the tech blogsphere. I just spent way too long googling how to do something I once knew how to do without googling. So much struggle.

This first post is a super super sloppy how-to for making my dev VM's image bigger. The math/steps/somethings may be off because my laptop CRASHED in the middle of the partition resizing the first time (Thanks systemd. No, really. I have a coredump to prove it.), and I had to backtrack and fill in some blanks. Post-crash, I made sure to start a screen session on the server in the lab just in case.

===
Background: My swap partition was at the end of the disk, so I wanted to grow the middle partition (to keep my data in tact), and then re-add the swap back to the end.

1. qemu-img resize ubuntu-15.img +25G

3. use parted to resize partitions:

[root@localhost ~]# parted /var/lib/libvirt/images/ubuntu-15.img
GNU Parted 3.1
Using /var/lib/libvirt/images/ubuntu-15.img
Welcome to GNU Parted! Type 'help' to view a list of commands.

[If I had the original print output you could see the original three partitions, but this just shows two because I'd done a recover to get the 2nd one back after I deleted (which is when my laptop kicked it) it so I knew it's old start.]

Number Start End Size File system Name Flags
1 1049kB 8389kB 7340kB prep
2 8389kB 15.4GB 15.4GB ext4

[my math:]
disk is now 42.9 G, so 2G swap, ~38G disk
38G is 39845888kB
start = 8389kB
end = 39845888 + 8389 = 39854277kB

rm 2
mkpart
name []
type: ext4
start? 8389kB
end? 39854277kB

mkpart
name [] swap
type: linux-swap
start? 39.9GB
end? 42.9GB

(parted) print
Model: (file)
Disk /var/lib/libvirt/images/ubuntu-15.img: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 8389kB 7340kB prep
2 8389kB 39.9GB 39.8GB ext4
3 39.9GB 42.9GB 3093MB linux-swap(v1) swap

quit

4. use resize2fs to fill in filesystem into newly expanded partition
- Boot into VM

~> df -h shows that /dev/sda2 is /

~> sudo resize2fs /dev/sda2
[sudo] password for christy:
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 3
The filesystem on /dev/sda2 is now 9728000 (4k) blocks long.

5. Re-create swap

~> sudo mkswap /dev/sda3
spits out something I didn't copy, but it includes your new UUID:
Grab that now.
UUID= 1cc8a190-ef01-4b07-b139-e1cef94b379c

~> sudo swapon -U UUID
 
6. Update fstab
~> sudo vi /etc/fstab
 change UUID from old one for swap to new one 
~> mount -a 
 
7. ~> sudo vi /etc/initramfs-tools/conf.d/resume # update with new swap UUID
8. ~> sudo update-initramfs -u 
 
Magical.