After running Andrew Lyon’s Gentoo patches for Xen kernel for quite a while on my Archlinux install, it’s unstability instability on my work machine (which can mainly be tracked down to Kernel Mode Setting issues inside the kernel code).

I have faced two ways to fix the issues I have been having on this particular machine: either fix the kernel code with the KMS patches (linked to above) or try a newer version of the OpenSUSE patches.

I have tried on and off the KMS patches, but either the build always fails somewhere or the machine simply will reboot just before Dom0 loads. To fix the issue, I have simply gone to rebuild a new kernel from OpenSUSE’s KoTD source.

Recorded here is the quick hacky steps taken to get the kernel building on my machine:

1. Download the kernel-source rpm from ftp://ftp.suse.com/pub/projects/kernel/kotd/master/src/
2. Extract the RPM.

   [tim@myhost ~]$ pacman -Qo `which rpmextract.sh`
   /usr/bin/rpmextract.sh is owned by rpmextract 1.0-4
   

3. for x in `find | grep \.bz2 `; do tar -xvf $x; done

4. for p in $(./guards $(./arch-symbols) < series.conf | grep -v ia64); do
       echo "--> $p"
       patch -d linux-2.6.35 -p1 < $p || break
   done

5. cp config/x86_64/xen linux-2.6.35/.config

6. cd linux-2.6.35

7. make oldconfig

8. make

Will it fix all my complaints that I have about my current kernel? Who knows, but I hope it does!

• —r: the paravirtualised/hypervised “domain” is currently running some sort of process.
  A domain will not be in the running state (“r”) if it was just waiting for a packet to arrive or a mouse to be moved —
• b: blocked, domain is waiting for something, usually an interrupt (for example, waiting for hard-disk data to be passed over to the domain). Also ,things like “sleep 5″ in the shell would cause “blocked”, as the domain is waiting for a number of timer ticks (5 seconds worth of) to pass.
• —p: paused – the domain has been paused with the command:xm pause (domain)
• —c: crashed – when a paravirtualised domain (or an “enlightened” Windows install) crashes (kernel panic / BSOD etc) the hypervisor will detect this and put the machine into a crashed state.
• d: dying – Something has told the domain to “kill itself” (such as “xm shutdown/destroy”, but it’s not yet disappeared. It’s probably there for the purpose of avoiding race-conditions where something is killing the domain, and something else is talking to it (for example disk accesses)

‘xm’

• —The xm program is the main interface for managing Xen guest domains. The program can be used to create, pause, and shutdown domains. It can also be used to list current domains, enable or pin VCPUs, and attach or detach virtual block devices.
• All xm operations rely upon the Xen control daemon, aka xend. For any xm commands to run xend must also be running. For this reason you should start xend as a service when your system first boots using xen.
• —Most xm commands require root privileges to run due to the communications channels used to talk to the hypervisor. Running as non root will return an error.
• Most xm commands act asynchronously, so just because the xm command returned, doesn’t mean the action is complete. This is important, as many operations on domains, like create and shutdown, can take considerable time (30 seconds or more) to bring the machine into a fully compliant state. If you want to know when one of these actions has finished you must poll through xm list periodically. —

xm create [-c] configfile [name=value]

• The create sub command requires a config file and can optionally take a series of name value pairs that add to or override variables defined in the config file.
• NOTE: Create will return as soon as the domain is started. This does not mean the guest OS in the domain has actually booted, or is available for input.
• -c Attach console to the domain as soon as it has started. Useful for determining issues with crashing domains.

xm info

Print information about the Xen host in name : value format. When reporting a Xen bug, please provide this information as part of the bug report.

 host                   : tim-pxe-xc02
 release                : 2.6.32.3-timg
 version                : #1 Mon Jun 02 14:26:26 EST 2010
 machine                : x86_64
 nr_cpus                : 1
 nr_nodes               : 1
 sockets_per_node       : 1
 cores_per_socket       : 4
 threads_per_core       : 2
 cpu_mhz                : 3330
 hw_caps                : 0383fbff:00000000:00000000:00000040
 total_memory           : 16384
 free_memory            : 37
 xen_major              : 4
 xen_minor              : 0
 xen_extra              : -devel
 xen_caps               : xen-4.0.1-x86_64
 xen_pagesize           : 4096
 platform_params        : virt_start=0xfc000000
 xen_changeset          : Mon Nov 14 18:13:38 2010 +0100
                          21226:7dcfdd45bc9e
 cc_compiler            : gcc version 4.5.0
 cc_compile_by          : timg
 cc_compile_domain      : beast.timg.local
 cc_compile_date        : Mon May 21 12:16:48 EST 2010
 xend_config_format     : 2

…

The standards, PCI-DSS (Data Security Standard) were developed to ensure that card holder’s data security was always kept to the highest possible standards.

To reduce the scope of assessment for any network that involves credit card data, it is extremely important that as little credit card data as possible is stored – and if that credit card data is actually stored on a network, that as few machines as possible have direct access to that credit card data.

This could be done in many particular ways. For example, any remote machines cannot access credit card information once encrypted. Storing the data on a separate network then that of the public network (read: internet) will ensure that your scope of assessment area.

If possible, never transmit credit card data over a wireless network. Seriously. The second that you add a wireless network into the credit card mix, your PCI assessments become much more complex – and much more expensive. When possible, keep the credit card data over wires. Wires are easy to see and difficult to listen in on.

There are 12 requirements inside the PCI DSS document.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Under this requirement, the person who is assessing your network for PCI DSS compliance is going to look over your entire network that touches any credit card information.

The first thing your assessor is going ask for is all of the firewall and router configurations. He is also going to check and ensure:

• processes are put into place for testing and approving changes to router and firewall configurations.
• processes exist for any new connections inside the network
• there are valid network diagrams.
  • Must document all connections to cardholder data
  • Must document the flow of CC Data
• the network diagrams that exist are up to date and valid.
• the current network diagram is consistent with the firewall configuration standards.
• that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.
• that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.
• that any insecure services, ports and protocols are necessary (ie, HTTP, FTP).
  • Yes. It’s true. You can’t run HTTP unless you have a reason for running it! If it’s not HTTPS it should not be on your credit card data network!
  • that firewall and router configuration standards require review of firewall and router rule sets at least every six months.
    • The assessor will actually check and ensure that reviews of the firewall and router rules have been performed. Ensure that you can leave a paper trail.The way that I recommend doing this is by storing the router and firewall configurations on a Mercurial repository, then allow the person who is assessing the configurations to actually sign the fact that they have verified the configuration by tagging the config and then allowing the reviewer to commit and check in the configuration file to the (private) Mercurial repository.
• that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows:
  • that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented.
    • updates to operating system and applications should not be done on the public network, especially for anything that handles any credit card data. This means having copies of the update repositories for Windows (WSUS) and Linux (rsync? etc) inside the local CC transaction network.Machines handling credit card processing should only talk to the Internet through secure protocols (SSH, HTTPS), and the internet should not talk to the machines!
• all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.
• router configuration files are secure and synchronized—for example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are re-booted), have the same, secure configurations.
• a DMZ is implemented to limit inbound and outbound traffic to only protocols that are necessary for the cardholder data environment and that inbound Internet traffic is limited to IP addresses within the DMZ.
• there is no direct route inbound or outbound for traffic between the Internet and the cardholder data environment
• internal addresses cannot pass from the Internet into the DMZ
• the database is on an internal network zone, segregated from the DMZ.
• the firewall performs stateful inspection (dynamic packet filtering)
  • run a port scanner on all TCP ports with “syn reset” or ”syn ack” bits set—a response means packets are allowed through even if they are not part of a previously established session
  • only established connections should be allowed in, and only if they are associated with a previously established session

Another post will be uploaded tomorrow explaining some of the details that you should include in your Network Diagram, plus some tips for ensuring all of the requirements in the first section are covered.

I can’t really tell that much just yet on what the application actually does, that’s top secret – but if you would like to be apart of the future, drop me a comment and I will send you the link to the download. The ISO is currently ~900MB, and a new updated version is released on my FTP server every 14 days.

Updating the system is simple, as it’s a rolling release. Just drop yourself into a console and type ‘pacman -Syu’ or click the ‘Update Software’ button in the user interface.

Alpha testers must be able to show a commitment to the Open Source community, and be willing to help write missing documentation for specific features.

Testers will need to be able to use BIND, MySQL, Apache, asciidoc, Xen, OpenVZ and a few other cool open source applications to be able to test the software and see it’s full potential (and fix things when it breaks…)

I have built a set of RPMs for all the servers there so that installing NRPE is basically done in two steps, and can be done completely hands off (if your hostname is set up correctly – which sometimes is not done).

Step One

Install the Nagios repository into /etc/yum.repos.d/

wget http://software.digitalpacific.com.au/repos/nagios.repo -O /etc/yum.repos.d/nagios.repo

Install NRPE

yum install dp-nrpe dp-nagios-plugins

Step Two

Do a few basic configuration file edits!

BOB=`hostname -i`; sed -i \
     /etc/nagios/nrpe.cfg -e "s/^server_address=\(.*\)$/server_address=$BOB/"
chkconfig --add nrpe
service nrpe start
service nrpe restart

If NRPE restarts you know you have done well!

This year is going to present some fun times. My code for autodeploying servers with predefined settings on them (eg, MySQL clusters, HTTP clusters) should be released some time soon. Also, ShareSource’s compile farm will go live. Another exciting project will be unleashed onto the world, but you will have to wait for that!

See you soon,
Tim

A few days after I moved to Sydney I found this very awesome book store near Central Station called Basement Books. Seriously, WOW.

Basement Books, conveniently located in central Sydney, offers 8kms and over 10,000 titles of discounted books with savings of up to 90% of recommended retail prices.

Even though the book I was specifically looking for was not there in the shop, in true Tim style I did walk out with about 1.5KGs worth of books. I suppose the only bad part of that was it was only two books.

I was looking for a book on C, because my skills have deteriorated greatly after not really writing much C code for at least 24 months.

• MySQL Developer’s Library, by Paul DuBois; and
• ANSI C++, The Complete Language by Ivor Horton.

I have started reading the book by DuBois, and it is a very well written; easy to understand, and it does include a very huge section about writing C applications; so it’s a win situation anyways, because I imagine that if I did write a complete C application, it would use MySQL in some way.

If your ever in Sydney, I would highly suggest going to the Basement Books store. It has amazing books… at amazing prices. Also, if you want to learn everything there is to know about MySQL, get this book. I only discovered partitioning for MySQL databases a few months ago when reading an article at work, and have loved the idea ever since. To have a nice section inside this book with practical examples for using partitioning has started to get my mind ticking.

It only took me about one minute, but I thought I might just write down the quick and dirty hack that I just did to get NoMachine’s free terminal server package (which allows two clients to connect at a time…) on Linux.

# sudo su -
# cd /tmp/nx
# wget http://64.34.161.181/download/3.4.0/Linux/FE/nxserver-3.4.0-8.x86_64.tar.gz http://64.34.161.181/download/3.4.0/Linux/nxclient-3.4.0-5.x86_64.tar.gz wget http://64.34.161.181/download/3.4.0/Linux/nxnode-3.4.0-6.x86_64.tar.gz
# echo the above URL’s may no longer be correct at the time of you reading this, please check http://www.nomachine.com/download-package.php?Prod_Id=1351
# cd /usr
# tar -xvf nxclient-3.4.0-5.i386.tar.gz
# tar -xvf nxnode-3.4.0-6.i386.tar.gz
# tar -xvf nxserver-3.4.0-8.i386.tar.gz
# ln -s /etc/rc.d /etc/init.d
# sudo /usr/NX/scripts/setup/nxnode –install redhat
# sudo /usr/NX/scripts/setup/nxserver –install redhat
# rm /etc/init.d

All the errors that the installer comes up with can be safely ignored.