$ facter --version
1.7.1

Now, before the Vagrantfile changes, your facter facts will look like this. The solution is within the :shell provider, in the first few lines of the Vagrantfile.

$ facter | grep 'custom'
[empty]

Your Vagrantfile can now be modified to look like this, to set up custom facts.

Vagrant::Config.run do |config|
  # First: run a shell provisioner to set up the custom facts
  config.vm.provision :shell do |shell|
    shell_cmd = ""

    # Make sure the facts directory exists
    shell_cmd << "mkdir -p /etc/facter/facts.d/; "

    # Add as much of these lins for any custom fact you want
    shell_cmd << "echo 'custom_fact1=the value of the fact' > /etc/facter/facts.d/custom_fact1.txt; "

    # Run the inline shell to create those facts
    shell.inline = "#{shell_cmd}"
  end

  # Then: run puppet like you normally would
  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = "manifests"
    puppet.manifest_file = "my_manifest.pp"
  end
end

After a 'vagrant provision', your facts will be updated.

$ facter | grep custom
custom_fact1=the value of the fact

And you can now use the $::custom_fact1 variable within your manifests/modules.

Update 16/5: as Dieter De Meyer pointed out, there's a more elegant solution using the puppet provider itself. The downside is the facts are only available if you use 'vagrant provision' to start a Puppet run, if you use Puppet from within the virtual machine, these facts won't be present (see the Vagrant Helper Scripts for Puppet to speed up your Puppet deployments).

Vagrant::Config.run do |config|
  config.vm.define :test do |vmconfig|
    vmconfig.vm.provision :puppet do |puppet|
      puppet.manifests_path = "manifests"
      puppet.manifest_file = "test.pp"
      puppet.module_path = [ "../", "./modules" ]
      puppet.facter = {
        "custom_fact1" => "value1",
        "custom_fact2" => "value2"
      }
      puppet.options = "--verbose"
    end
  end
end

Thanks!

$ service nginx configtest
nginx: [warn] load balancing method redefined in /etc/nginx/conf.d/upstream.conf:5
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

This can occur when you conflicting variables inside your upstream, like such:

$ cat upstream.conf 
upstream upstream_name {
  # Use max # keepalive connections
  keepalive 120;
  # Use the backend with least number of connections
  least_conn;
  # All upstream members defined below
  server 192.168.1.5:80  weight=24;
  server 192.168.1.6:80   weight=24;
}

The warning is causde by the mixing of 'keepalive' and 'least_conn', use either one but don't mix both.

configure: error: C++ compiler g++ does not work or no compiler found

Solution:

$  yum install gcc gcc-c++

And that's it.

$ rvm install 1.8.7
Searching for binary rubies, this might take some time.
No binary rubies available for: osx/10.8/x86_64/ruby-1.8.7-p371.
Continuing with compilation. Please read 'rvm mount' to get more information on binary rubies.
The provided compiler '/usr/bin/gcc' is LLVM based, it is not yet fully supported by ruby and gems, please read `rvm requirements`.

That sucks. Work-around as such:

$ rvm install 1.8.7 --with-gcc=clang 
Installing Ruby from source to: /Users/name/.rvm/rubies/ruby-1.8.7-p371, this may take a while depending on your cpu(s)...
ruby-1.8.7-p371 - #downloading ruby-1.8.7-p371, this may take a while depending on your connection...
ruby-1.8.7-p371 - #extracted to /Users/name/.rvm/src/ruby-1.8.7-p371 (already extracted)
Patch stdout-rouge-fix was already applied.
Patch no_sslv2 was already applied.
ruby-1.8.7-p371 - #configuring
ruby-1.8.7-p371 - #compiling
Error running 'make', please read /Users/name/.rvm/log/ruby-1.8.7-p371/make.log
There has been an error while running make. Halting the installation.

Which also sucks. Turns out rvm sort of bugs out for Ruby compiles if it includes tk/tcl support, something you most likely don't need anyway. Workaround is as such:

$ rvm install 1.8.7 --with-gcc=clang --without-tcl --without-tk
Installing Ruby from source to: /Users/name/.rvm/rubies/ruby-1.8.7-p371, this may take a while depending on your cpu(s)...
ruby-1.8.7-p371 - #downloading ruby-1.8.7-p371, this may take a while depending on your connection...
ruby-1.8.7-p371 - #extracted to /Users/name/.rvm/src/ruby-1.8.7-p371 (already extracted)
Patch stdout-rouge-fix was already applied.
Patch no_sslv2 was already applied.
ruby-1.8.7-p371 - #configuring
ruby-1.8.7-p371 - #compiling
ruby-1.8.7-p371 - #installing 
Retrieving rubygems-1.8.25
Extracting rubygems-1.8.25 ...
Removing old Rubygems files...
Installing rubygems-1.8.25 for ruby-1.8.7-p371 ...
Installation of rubygems completed successfully.
Saving wrappers to '/Users/name/.rvm/bin'.
ruby-1.8.7-p371 - #adjusting #shebangs for (gem irb erb ri rdoc testrb rake).
ruby-1.8.7-p371 - #importing default gemsets, this may take time ...
Install of ruby-1.8.7-p371 - #complete

Win!

$ rvm list

rvm rubies

   ruby-1.8.7-p371 [ i686 ]
   ruby-1.9.2-p320 [ x86_64 ]
   ruby-1.9.3-p374 [ x86_64 ]

 [  proc ] mysql_stmt_execute failed: Unknown prepared statement handler (1) given to mysqld_stmt_execute -> libgearman-server/plugins/queue/mysql/queue.cc:356
 [  proc ] gearman_server_job_add gearman_server_run_command(QUEUE_ERROR) -> libgearman-server/server.cc:284

The above is visible from the /var/log/gearmand/gearmand.log logs, that which calls the queue will fail with an error message as such:

Warning: GearmanClient::doBackground(): _client_run_tasks(GEARMAN_SERVER_ERROR) queue_insert_error:QUEUE_ERROR -> libgearman/client.cc:1522 in /path/to/script.php on line xxx

The solution is relatively simply: you probably don't have the uuid package installed. The package is meant to generate unique IDs that Gearman would use to assign to each job, without the package the unique ID's can not be generated. If you're running a MySQL persistent backend for your Gearman, inserts would fail without such a unique ID because of primairy key violations.

As such, install it:

$ apt-get install uuid
$ yum install uuid

Depending on your OS, use either apt/yum.

# Remove all cookies for static files
if (req.url ~ "^[^?]*\.(css|jpg|js|gif|png|xml|flv|gz|txt|...)(\?.*)?$") {
  unset req.http.Cookie;
  return (lookup);
}

The snippet above will strip all cookies from static files causing them to be cached by default. Why do I dislike this? Because it seems like this is causing people to cheer at their 99% cache hitrate but is causing more cache evictions because their memory is so limited. The only moment you should ever cache static file is if you have memory to spare.

Static files do not cause load.

Sure, they cause disk access. Not just for reading the file, but for logging their entry in the webserver logs as well (if you have not excluded caching static content from your server logs). And your webserver needs to send the file back to the client.

But in all likeliness, your OS probably has your most frequent static files in their buffer meaning no disk access is required to serve the file. And your webserver should simply be good at serving static files, or you should consider switching (to, say, lighttpd or nginx).

You're staring blindly at the cache rate

If a default config caches all static files without exception, you'll see high cache hitrates. You (and your client) will be happy. And you'll be mislead in thinking that the performance bottlenecks have been solved. It's not the static files that cause your webserver load, it's the PHP/Ruby/Perl/... scripts that are hitting your database and are calling external API's. Those are the requests that need to be cached, not a static file that's not causing any CPU load.

Proceed with spare memory

Therefore, focus should be given to the dynamic pages causing server load. Those cached requests actually make a difference. Then, if you have spare memory, open up some static file requests to be cached. And continue to monitor your cache size, because if static files are causing heavy PHP pages to be evicted from memory, you will only hurt your performance further.

Nearly no one has the capacity to store all their static content in a Varnish memory cache. Don't sacrifice a 5ms static file request for a 500ms PHP processing script. I've commented all entries that cause static files to be cached explaining this, and I hope that people don't blindly copy the config templates but read through them and think about this.

It's not that convenient that the repository is offline then, is it? With no sign yet on when it's coming back, we dedicated to announce our own jPackage mirror for the time being, until the official ones come back. It won't be updated (since the upstream appears to be dead), but for new installs it may still be usefull.

You can find the mirror at http://mirror.nucleus.be/jpackage/, with an example Yum Repository file included.

Hope it helps!

That 960×640 pixel iPhone display is dominating me. It needs to stop. Now.

I'm already spending an unhealthy amount of time in front of a laptop, tablet or smartphone so that every time I'm away from them -- I should really be away, you know? No distractions. Nothing to pull me back in. Enjoy the non-digital life.

The last few weeks I've been able to do this better, with the help of a few little tweaks to how I work.

Disable notification sounds

Among the first things I had to disable were the notification sounds that every application on the iPhone makes by default. It's a silly thing, and I'm sure some can resist this urge, but whenever I hear that notification sound I have to check what it is.

Even if it's something meaningless as a Retweet on Twitter or a tag on Facebook, I was distracted and stopped whatever I was doing to check it. Disabling these sounds made my life, quite literally, calmer.

A cleaner homescreen

As most iPhone users, my default home-screen on the device consisted of the Twitter/Facebook app, the Mail, Phone and Messages app, the Camera and the Music player (Spotify in my case). This default layout resulted in me seeing the amount of new e-mails I had every time I would take a picture or change a song on my phone.

With every relaxing action I would normally do, such as look at pictures, use the Camera app to take new ones, change a song, browse the net, ... I would see that big Mail icon with the even bigger 'Unread Mail' counter on it. That also meant that I would open my Mail app nearly every time I unlocked the phone to see what was new.

I'm jealous of people that can leave their work on a Friday evening and never look at it again until Monday. I know I'll never be able to do that, but by simply moving those distractions away to another screen on the phone I'm able to relax more and not think of work all the time.

The left screen was my normal configuration. I would always see how many mails were awaiting me, I couldn't resist opening the Facebook or Twitter app on every notification, ... I was addicted.

The right screen is the new way to go: Mail is no longer present on the main screen, the Facebook & Twitter app have been moved back as well, notifications from work (Prowl) moved to another screen, ... Less big red numbers flashing in my eyes and distracting me.

Whenever I open my Mail app now, it's deliberate with the purpose of actually reading and replying to emails.

More structure in e-mails: Kukoo

Simply moving a few icons around helped, but only on the smartphone. I would still get all my mails on the laptop. And since I managed my appointments and contacts in the same application that also receives my mail (Outlook), it meant that whenever I opened it, I'd received all my new mails and feel at work once again.

To get a calmer mailbox with less distractions, I've been using Kukoo for around 2 months now and it's helped me tremendously. With Kukoo, I decide when mail will be delivered into my mailbox. Even if I open my Outlook to check an old e-mail or my calendar, I won't get any new mails because that's how I configured it. The mails will only be delivered when I want it.

And since I'll be reading my e-mails less, I need to alert my correspondents that would normally received a reply back within 30 minutes that it'll take a bit longer this time. For that, I have a public page that displays when I'll read my next mails: kukoo.com/mattias. It's present in my mail signature so the people I mail with know about it. For new mails that I receive, I can send an autoreply with the exact time that I'll be reading my mail again.

In the meantime? I can focus on my work or on relaxing properly once again.

1 + 1 = relax

Those 2 changes mentioned above, modifying the smartphone to be less present and using Kukoo for a more structured mailbox, have helped me a lot. I'm able to get away from my digital life more often and enjoy the real life around me.

I'm sure for some this seems like overkill or perhaps blown out of proportion, but for me these changes were a necessity. Life is busy enough as it is, you need to make time to calm down and enjoy the non-work life from time to time. :-)

For instance, to troubleshoot some iSCSI connectivity problems, you would be used to doing something as this.

~ # telnet 10.0.2.3 3260
-ash: telnet: not found

Instead, you can use netcat to test the connectivity.

~ # nc -z 10.0.2.3 3260
Connection to 10.0.2.3 3260 port [tcp/*] succeeded!

If you were to test this on a closed TCP port, the error would look like this.

~ # nc -z 10.0.2.3 32600
(empty response)

The result is that any system still using that blacklist sends out bounce messages such as this.

The following recipient(s) cannot be reached: xxx
Service unavailable; Client host [x.x.x.x] blocked using list.dsbl.org

If you still have legacy systems running that use the list.dsbl.org blacklist, you may want to remove any references to the DSBL in your configs and stop using that blacklist.

$ e2fsck -p -f /dev/vg_mnt/lv_mnt01
/dev/vg_mnt/lv_mnt01: Error allocating icount structure: Memory allocation failed
/dev/vg_mnt/lv_mnt01: Error allocating directory block array: Memory allocation failed
e2fsck: aborted

This happens because the e2fsck tries to store all inode information in memory, which may exceed the available memory size on the system.

To fix this, either upgrade the system with more memory or try to set additional options that allow e2fsck to create a temporary directory on a system with sufficient (several GB's) free disk space. Not that this only works for e2fsck version 1.40 or higher (meaning: CentOS and RHEL users are screwed since they only provide 1.39).

$ rpm -qa | grep e2fsprogs
e2fsprogs-libs-1.39-34.el5_8.1
e2fsprogs-devel-1.39-34.el5_8.1
e2fsprogs-1.39-34.el5_8.1

To run the e2fsck with a recent version, try the following.

$ cd /usr/local/src
$ wget "http://kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.42.5/e2fsprogs-1.42.5.tar.gz"
$ tar xzf e2fsprogs-1.42.5.tar.gz
$ rm -f e2fsprogs-1.42.5.tar.gz
$ cd e2fsprogs-1.42.5
$ yum install gcc make
$ ./configure
$ make

The above will download e2fsck (the latest version as of this writing), compile and make it but leave it in the directory of the build (/usr/local/src/e2fsck), it won't copy the binaries to your system. That means you can use the newly compiled binary at /usr/local/src/e2fsprogs-1.42.5/e2fsck/e2fsckw.

Now, since you have a e2fsck version higher than 1.40, you can set the options to use a scratch-disk and avoice the Out-of-Memory errors. First, create the directory.

$ mkdir -p /var/cache/e2fsck

And create a custom file called /etc/e2fsck.conf that contains the following content.

$ cat /etc/e2fsck.conf 
[scratch_files]
directory = /var/cache/e2fsck

This tells e2fsck to use a directory on disk if the total available memory is insufficient to host all inode information of the partition.

If you had to make a new e2fsck yourself because the OS didn't have a recent version, start the new e2fsck as such.

$ /usr/local/src/e2fsprogs-1.42.5/e2fsck/e2fsck -f /dev/vg_mnt/lv_mnt01

If you had a recent version already, you can simply restart e2fsck with the system binary.

$ e2fsck -f /dev/vg_mnt/lv_mnt01

When the new e2fsck is running, you should see additional information appear in the cache-directory.

$ ls /var/cache/e2fsck/
total 475M
-rw-------  1 root root 106M Aug  5 13:16 2fb8a70e-8ee3-4c9c-b95b-0e42ae1ecebd-dirinfo-jthsIm
-rw-------  1 root root 368M Aug  5 13:16 2fb8a70e-8ee3-4c9c-b95b-0e42ae1ecebd-icount-ZxFa0u

If the directory is empty, your e2fsck is not using the scratch_files options set in /etc/e2fsck.conf and would probably indicate that it is running an older version that does not yet support this. See the compile commands above to compile the latest version yourself.

Happy fscking!

$ facter
Could not retrieve selinux: Invalid argument - /proc/self/attr/current
Could not retrieve selinux: Invalid argument - /proc/self/attr/current
Could not retrieve selinux: Invalid argument - /proc/self/attr/current
Could not retrieve selinux: Invalid argument - /proc/self/attr/current
...

After checking the sestatus, it should have been disabled.

$ sestatus
SELinux status:                 disabled

Yet the /selinux directory on the server contained content that would contradict that.

$ ls -alh /selinux/
total 20K
drwxr-xr-x  2 root root 4.0K May 11  2011 .
drwxr-xr-x 23 root root 4.0K Jul 31 11:27 ..
-rw-r--r--  1 root root    2 Oct  6  2010 enforce

That file should not be there if the selinux is in fact disabled. If all selinux related configurations have been disabled (as verified by sestatus and the selinux config file at /etc/selinux/config) you can safely remove that file.

$ rm -f /selinux/enforce

The Puppet/Facter code would check if that file exists in the /selinux directory -- if that does not fully match your selinux config, you can get funky messages as the ones shown above.

Obviously, you don't want this. The good news is, this is fairly easy to prevent.

Using flock

Flock is a very interesting tool for managing lock files. Those lock files are used to determine if a script or application is already running (comparable to a PID file that contains the Process ID of the running script). If the lock exists, the cronjob won't start. If the lock doesn't exist, it's safe to launch the cron.

Take the following common example, where a cron is run every minute on the server.

$ crontab -l
* * * * * /usr/bin/php /path/to/cron.php

If the script takes longer than a minute to execute, they'll begin to overlap. To prevent it, you can change it with the flock example below.

$ crontab -l
* * * * * /usr/bin/flock -w 0 /path/to/cron.lock /usr/bin/php /path/to/cron.php

The example above requires flock to manage those lock files. If it does not yet exist on your system, installation should be as simple as a yum install flock or apt-get install flock, depending on your Linux Distribution (see: how to find your current Linux Distribution).

The moment flock starts, is locks the lock-file you specify in the command. You can see that by requesting the user/script that is having the lock on that file.

$ fuser -v /path/to/cron.lock
                     USER        PID ACCESS COMMAND
cron.lock:           root       7836 f.... flock
                     root       7837 f.... php

It will show you the Process IDs (PIDs) of the script that is holding the lock. If no script is holding the lock, the fuser command will simply return nothing.

$ fuser -v /path/to/cron.lock

So flock is a pretty good way to prevent cronjobs from overlapping by using an extra Command Line tool.

Using pgrep

Another method, without using lock files, is using a rather simple bash-one liner that checks for the current running file and executes it if it's not running. The trick is to wrap your crontask in a uniquely-named bash-script, as such.

$ cat /path/to/cron.sh
#!/bin/bash
/usr/bin/php /path/to/cron.php

$ chmod +x /path/to/cron.sh

In your crontab, it should be listed as such now.

$ crontab -l
* * * * * /path/to/cron.sh

The command above will, just as the first example, execute our PHP script every minute through a bash script. To prevent it from overlapping, it can also be changed to this.

$ crontab -l
* * * * * /usr/bin/pgrep -f /path/to/cron.sh > /dev/null 2> /dev/null || /path/to/cron.sh

The pgrep command will return false if it does not find a running process matching the first argument, /path/to/cron.sh. If it returns false, it'll process the second part of the OR comparison (the double vertical line, ||). If the running process was found, pgrep will return the Process ID (PID) and Bash will not continue to the second part of the OR statement since the first already returned true.

The trick here is to use very unique scriptnames. If the name is too generic (such as "cron.sh"), pgrep may return Process IDs from other running cron jobs and not execute the cron you wanted.

Using lock-files within the script

If the examples above are not available to you, you can still use the concept of lock files in your application. One of the first commands in your script could be to check for the existance of a lock-file. If it exists, the script would simply exit(1) out of the application and stop running. If the lock-file does not exist, the script could create it and prevent the next job from executing.

As a last step in your script you remove the lock file to indicate that the script has finished and allowing the next run to continue.

# yum reinstall kernel
Package kernel-2.6.18-194.32.1.el5.x86_64 is allowed multiple installs, skipping
Package kernel-2.6.18-274.12.1.el5.x86_64 is allowed multiple installs, skipping
Package kernel-2.6.18-194.el5.x86_64 is allowed multiple installs, skipping
Package kernel-2.6.18-308.1.1.el5.x86_64 is allowed multiple installs, skipping
Package kernel-2.6.18-308.11.1.el5.x86_64 is allowed multiple installs, skipping
Nothing to do

To reinstall the kernel, you actually have to remove it first and then install it again. You can remove your currently running kernel since it's operating completely from memory and does not rely on the physical files at the moment you're trying to reinstall it. So, first find out your current version.

# uname -r
2.6.18-308.11.1.el5

And see what other kernels you may have installed.

# rpm -qa | grep kernel | sort
kernel-2.6.18-194.32.1.el5
kernel-2.6.18-194.el5
kernel-2.6.18-274.12.1.el5
kernel-2.6.18-308.1.1.el5
kernel-2.6.18-308.11.1.el5
kernel-headers-2.6.18-308.1.1.el5

If you don't need the older kernels, you can safely remove them. You should keep at least one extra, just in case this reinstall fails (or if the new kernel is giving you problems).

# yum remove kernel-2.6.18-194.32.1.el5 kernel-2.6.18-194.el5

Now, to reinstall the kernel you want, first remove it by specifying the exact version (usually the currently running kernel, see uname -r above).

# yum remove kernel-2.6.18-308.11.1.el5
=====================================================================
 Package       Arch       Version               Repository    Size
=====================================================================
Removing:
 kernel        x86_64     2.6.18-308.11.1.el5   installed     98 M

Transaction Summary
=====================================================================
Remove        1 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

Is this ok [y/N]: y

Confirm that the kernel is actually removed.

# rpm -qa | grep kernel | sort -n               
kernel-2.6.18-308.1.1.el5
kernel-headers-2.6.18-308.11.1.el5

It's not showing up (only the older kernel), so reinstall it.

# yum install kernel-2.6.18-308.11.1.el5
=======================================================================
 Package       Arch       Version              Repository      Size
=======================================================================
Installing:
 kernel        x86_64     2.6.18-308.11.1.el5  updates         21 M

Transaction Summary
=======================================================================
Install       1 Package(s)
Upgrade       0 Package(s)

Total download size: 21 M
Is this ok [y/N]: y

And you should see the Kernel appear again.

# rpm -qa | grep kernel | sort -n                
kernel-2.6.18-308.11.1.el5
kernel-2.6.18-308.1.1.el5
kernel-headers-2.6.18-308.11.1.el5

After that, reboot the server again to make sure everything went as expected and you should have a cleanly reinstalled Linux Kernel available to you (for whatever reason this may have been necessary).

You just need bigger buttons, right?

My though back then was: mobile websites? That's just the same as any other site, but with bigger buttons. You know, fat finger touching etc. Take a normal button, multiply it by x2, and done. You have a mobile site.

So with that in mind, I built the very first version of MoZBX using jQTouch, which back then was a combination of jQuery and some mobile enhancements (they now offer Zepto.js as well instead of jQuery, which seems to speeds it all up instead of the slow monster that I experienced jQuery to be on mobile devices). It was relatively easy to get a first prototype up and running, but it annoyed me. You see, I'm mostly a backend developer. I don't care about designs, I care about functional PHP code. I love to hack my solutions together in my own way and not have to follow rules other tools force me to use. I like my freedom.

That's when my frustration with jQTouch began: you needed certain ways of structuring your data, you need to follow strict rules on how to create forms, lists, styles, ... (with annoying submit-actions on forms, what's up with that jQTouch?), everything is being loaded via AJAX which makes UI testing a pain, ... It pulled the joy of creating a new project right out of me. MoZBX worked, but I wasn't happy with it. Windows Phone users couldn't access it, BlackBerry support was ... well ... a joke, ... I needed something else.

So I looked at other solutions, such as jQuery Mobile, Kendo UI, ... but none suited my needs. The reason I looked at those 'Mobile Frameworks' in the first place is my absolute lack of design skills, both in graphics and in CSS-styles.

Bootstrap FTW!

And then, out of the blue, came Twitter Bootstrap, which I shall name "a backend developer's wet dream for creating decent looking websites" from now on. So, trying to be hip and cool, I redid the UI for MoZBX in Twitter Bootstrap and threw away everything that was ever related to jQTouch. And there was much joy.

It took me a few evenings of work to test how Twitter Bootstrap worked, how I could use it in MoZBX and what would be the best way to get started. And a few days later, the new MoZBX was born.

Sites vs Native App

My conclusion so far is: throw away all those mobile frameworks you use if you want a mobile website. If you want those App-like feelings with swipe effects and page transitions, build an app instead. If you want a mobile site (see: it's even in the words, you're building a website, not an app), use plain old HTML and CSS for a responsive website. Stop hogging mobile UI's with frameworks that are overly complex and add overhead to each page request -- let alone the development overhead of adjusting the app to fit into that particular framework.

Granted, in 6 months, every website will look like it's been made with Twitter Bootstrap, but I don't blame them -- it's easy to use and it just works. No need to dabble in new 'frameworks' to get your mobile site going. Use CSS and HTML, create bigger buttons, and you've got yourself a mobile site.

Side note: if you're a graphics designer working on a mobile website for the last 6 months, I apologize for the overly simplified statement of 'mobile just means bigger buttons'. I do appreciate all the work you put into creating beautiful pages. For me however (and in particular, this monitoring project), it's overkill. I just needed bigger buttons.