Despite a never ending well of hate for windows, sometimes I have to work with it.

In this case I needed to create a glance image that could be deployed to a openstack cluster … and that is where the fun stops.

First things first, if you can do a clean install (if you paid the extra £20 and actually received your dvd media that is!) do so, the upgrade process from Windows 7 took the best part of 2 days to complete.

Secondly to create your glance image you’re going to have to do the installation on the same type of hypervisor that you have openstack running upon, in this case I will be covering deployment of Windows 8 onto Linux KVM with virtio drivers.

The kludge

You can not start the instance using virtio for the hard disk, it simply puts itself into a never ending recovery mode, instead set the bus type to SATA or IDE.

Attach a second drive that uses virtio bus, why you may ask? Windows 8 will now boot and in turn have a device attached which it can not recognize.

Before booting you will also need to attach this iso as a cdrom, at the time of writing you can use the Win7 drivers for Windows 8. (iso version 0.1-30)

Square peg, round hole == Bigger hammer

I opted to first install all the drivers by opening up the virtual cdrom, navigating to the Win7 folder and: right click -> install on all the “Setup Information” files.

My “fun” did not end here however … because it would appear the attached virtio device was not formatted Windows8 decided to ignore it.

In this case the device manager needs to be launched to resolve the issue a laborious task in itelf.

1. Open desktop, and click the windows explorer tray icon.
2. Right click “Computer” and click properties.
3. Click “Device Manager”.
4. Expand the “Disk Drives” section, (if you did not install the drivers and reboot, you may be prompted to install the device, or it will show up as an unknown device instead of a disk drive)
5. Right click properties on the “RedHat VirtIO SCSI Device”
6. Click the volumes tab and click populate.
7. Close all windows leaving the Explorer window open.
8. Right click computer, select Manage.
9. Select disk management, partition and format the Virtio device as you would any other hard drive.
10. You should now have a new volume, this is running with the virtio drivers.
11. Shutdown windows.
12. Reconfigure the KVM instance, remove the VirtIO disk, change the primary disk bus to VirtIO
13. Start windows, and wait … and wait …
14. Once the start menu has booted you will begin to notice performance picks up after a while, I assume this is due to background tasks running.
15. Run any updates that may be outstanding and shutdown the instance. I would also advise configuring remove desktop
16. Convert to qcow2 (if you want), and import into glance as you would any other image.
17. Create or modify a security group if you have opted to allow Remote Desktop.

And boot the image as normal, ensuring that the selected “flavor” has enough disk space to start the instance.

As for meta data injection, for say account setup I have no idea at this time, please feel free to post in the comment or email me with methods for doing so.

Credits

this blog for noting the ‘dirty hack’ workaround in Windows 8 R2

and James P for having way more patience with windows than I will ever have.

If you come across this error

unable to load certificate 140735207381436:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1319: 140735207381436:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:381:Type=X509_CINF 140735207381436:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:751:Field=cert_info, Type=X509 140735207381436:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:pem_oth.c:83:

When trying to validate a certificate using openssl, this is because it is in the wrong format, whilst the certificate file visually appears to be in x.509 format, you will find it contains a far longer base64 string than x.509 certificats of the same bit length.

The format in this case is p7b (PCKS #7); to use the certificate witih apache you’re going to have to convert this.

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

Within the resulting .cer file you will file you x.509 certificate bundled with relevant CA certificates, break these out into your relevant .crt and ca.crt files and load as normal into apache.

Per my Google+ ramblings; recently I began experimenting with Percona XtraDB Cluster.

After an initial read the setup process seemed very simple, and as it would turn out it was; I later moved onto some simple resillience testing of my 4 node p.o.c. cluster.

I’m still a little unsure on the circular topology I ended up using; but it appears absolutely fine so long as the following conditions are met.

1. At least one node is always available.
2. Nodes are recovered only if their peer is available to sync from. a. Requiring a startup order.

This is not such a bad thing, as if all nodes were to suddenly go down; I can’t think of a situation where you would want it all to recover “automagically” you would want to inspect to ensure data integrity and recover from a “known good” version of your data.

Openstack as an experimentation platform

Openstack i I’ve found perfect for rapid prototyping of hostinsg platform architectures, in none geek building virtual models of servers and services; ensuring sure they all go together properly before committing to the build plan.

The best part being the VM’s are “Throw away”, something goes inexplicably wrong with a vm prototype? assuming you used snapshots at each step it’s easy enough to roll back.

For reference I used Fedora 17 and the wiki reference setup of openstack for prototyping.

Note in this case you may be better off using OpenVZ; whilst openstack does not at the time of writing support this directly, the openstack DBaaS (Database as a Service) project Red Dwarf leverages OpenVZ to provide DBaaS, (Something I’d like to get auto handeling clusters via XtraDB clustering, given the time …).

XtraDB cluster p.o.c. platform

My platform consists of 4 nodes; although I am sured an odd number of nodes is preferable to reduce the risk of split-brain behaviour occuring.

Following on from The Hooded Apache, I thought it was about time to cover Nginx configuration.

Nginx is not exempt from security issues, and as with apache certain versions can vulnerable to a specific attack, as such the first line of defense is you hide your nginx version.

This can be done via:

1
2
3
4

server {
    server_tokens off;
    ...
}

This changes the put from

1

Server: nginx/1.0.12

To

1

Server: nginx

You could if you are so inclined change the server string in the c code itself

src/http/ngx_http_header_filter_module.c

...
static char ngx_http_server_string[] = "Server: my_modified_server" CRLF;
static char ngx_http_server_full_string[] = "Server: my_modified_server/release_version" CRLF;
...

To err is human …

Sometimes standard responses can be used for service fingerprinting as such error documents could still give away your running server version even if you were to edit the header code as per above, again this could be done by modifying the C code to only return “” for each error page, in which case you will need to edit

src/http/ngx_http_special_response.c

...
static char ngx_http_error_301_page[] = "";

I’m not going to list all of them you should get the idea from the exmaple above; however this is not really required, you can also swap out the default error pages with standard configuration.

1

error_page 404 = /path/to/custom/404.html;

A strong Front …

Nginx ofetn gets used to proxy other services, as such you could be revealing the backend technologies in use due to the backend server sending headers such as X-Powered-By.

This where in your proxy configure options you can have nginx intercept and remove the headers being sent by the backend.

1

proxy_hide_headers X-Powered-By;

In this post I will cover growing the file system of a guest instance when running KVM linux.

For this you will require the following Packages:

1. libguestfs-tools
2. guestfish

Shutdown the instance

In order to grow the disk we must virsh shutdown the instance, this can be achieved using a simple virsh shutdown instance_name, try to avoid running a virsh destroy as we want a clean filesystem to avoid issues in the resize.

Get current image information

After the image has shutdown we can now go ahead and get some information on the disk configuration:

1
2
3
4
5
6

virt-filesystems --long --parts --blkdevs -h -a centos_centos6.qcow2

Name       Type       Size  Parent
/dev/sda1  partition  200M  /dev/sda
/dev/sda2  partition  9.8G  /dev/sda
/dev/sda   device     10G   -

As can be seen here there is a single 10GB virtual disk residing on /dev/sda

virt-rezise

We must then create a destination disk image, of the required total size

1

qemu-img create -f qcow2 outfile 150G

I have opted to use the –expand flag, if this is not specified a new partition is created to ocupy the free space, refer to man virt-resize for more advanced options such as splitting the freespace to grow existing partitions (i.e. expand the boot partition +100M)

1

virt-resize --expand /dev/sda2 original.qcow2 outfile.qcow2

Go make a coffee as this step will take a while to complete.

Finishing up

If you were to start the instance back up now using outfile.qcow2 as the disk image, you would find the OS reports the original disk size, this is due to the LVM configuration which we can not change “online” (unless of course you are changing a partition that can be unmounted, not the case here).

We will use guestfish to complete the process.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

guestfish --rw -a outfile.qcow2

Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.

Type: 'help' for help on commands
      'man' to read the manual
      'quit' to quit the shell

><fs> run
><fs> list-filesystems
/dev/vda1: ext4
/dev/VolGroup00/LogVol00: ext4
/dev/VolGroup00/LogVol01: swap
><fs> lvresize-free /dev/VolGroup00/LogVol00 100
><fs> resize2fs /dev/VolGroup00/LogVol00
><fs> e2fsck-f /dev/VolGroup00/LogVol00
><fs> exit

virt-df -h outfile.qcow2
Filesystem                                Size       Used  Available  Use%
centos_el6_php53_lap:/dev/sda1            194M        52M       132M   27%
centos_el6_php53_lap:/dev/VolGroup00/LogVol00
                                          146G       1.1G       137G    1%

Your lvm configuration may differ change the above according to the output from list-filesystems.

Note: I run e2fsck-f as a precaution, this is not a required step though I highly recomend doing this.

Now finally swap out the images (or update the libvirt xml file, it’s up to you)

1
2
3

mv ./original.qcow2 ./original.bak
mv ./outfile.qcow2 ./original.qcow2
virsh start instance_name

If you instance starts successfully and all your data is intact the original.bak can be safely removed.