Will mobile application developers endure? Or really, will businesses put up with prices and time taken to develop native mobile apps. Especially now when a third platform is joining. Up until now, it really only been 2 serious contenders, ios and android. Developing and coordinating development of a native application simultaneously on both platforms, especially with external consultants(sometimes different for each platform) can be a real timesuck. And now, windows phone is ramping up to become a real contender, if they will be is still left to see, but, from the upcoming fall and onwards, customers might expect your native app to be available and equally good on all three platforms.

Do we really want to handle yet another platform? If windows phone gets big, the best option would be to develop html5 mobile apps instead. Of course it have its own unique challenges, but at least its one codebase and multiple devices, as usual with webstuff.

The biggest obstacle is likely that customers expect apps to be in the appstore/market-play/windowsphoneequivalent, so handling webapps in the same way in the those marketplaces feels like the next natural step. Although, thinking about it, it seems unlikely apple will let go of their control of apps in such a way, and Apple is (unfortunately) probably the one of the three to have the most to loose, and will likely be more reluctant to adopting this. 

I hope we will see webapps within the appstore(with the ease of use that it means for the end user) really soon, but at the same time, it feels like Apple is having the advantage on their side with more high quality apps(and the default smartphone to think about) than android and windows phone. You could probably argue that Android have more apps, and perhaps with same/higher quality but Googles loose control unfortunately gives more crap to find your way around.

What do you think? Discuss at http://news.ycombinator.com/item?id=3763588

Reading the release notes of php 5.4.0 you get really curious, a lot of nice new features and promises of speed improvements are always welcome. 

I downloaded both the 5.3.10 and the 5.4.0 source, just to see the difference. Normally I used .deb-files from backports, but for this I compiled the source, just to get the defaults. And compiled a really simple one with:

./configure --disable-cgi --with-mysql

I took a few of the tests from http://www.phpbench.com/ just to have something basic to test with, and to my enjoyment 5.4.0 was faster on all the tests that I did. Especially the memory management seemed improved, the tests are really small so the speed improvements didnt show as much I guess. But comparing it memorywise, 5.4.0 used a third(1/3) of the memory of 5.3.10.

Really impressive!

February was a busy month, in many aspects, from an open source perspective, not much was done. I spent, according to Lets Freckle, 2 hours a 45 minutes. Most of the time was spent setting up a wordpress installation tracking its trunk. Original idea looking into wordpress was scratching a personal itch, to search a page by its slug. 

Beeing quite unfamiliar with wordpress codebase I spent about an hour trying to fix it myselft after filing the feature request. It will probably need some more time before I get a final fix for it. 

I also worked on a few small things with phpmyadmin, mainly the auto_increment reset feature when editing rows, still not done yet I noticed. Really good that lem9 is testing all the patches out, even though I’d hope my own testing was more thourough. :)

Also the patches from january for activating the codemirror sql editor here and here was accepted and successfully merged into master. Sweet, the world has improved, but theres still some stuff left to do… :)

I’m hoping this will be a returning post of mine, I’ve started a bit during the chrismas holidays and inventoring what open source projects I used the most and could most easily contribute to. The first aim was actually just to get involved in something that used git, so I could have some practice before switching to it entirely at work. But I realised this should be more continous than that. And also, its been a few years since I contributed or at least tried to squirrelmail and seagull. 

Since I do mostly web development, the linux-part didnt feel so likely, or contributing to gnome seemed far away. :)

I’ve been checking out Openphoto on github for a while since I’ve been wanting a self-hosted good and flexible image hosting thingie. So I started there, and actually found a bug, which I could fix with one single simple line. So I sent a pull request, and just like that I was more or less started.

After that I realised phpmyadmin is my everyday tool more or less, I started by setting up the latest master revision and checking the bug-list, to see if there was something that I could easily fix and get acquainted with the codebase. Since I set out to use the dev-master-version in my everyday use I quickly found some inconsistencies(and also found some new neat features), so I’ve filed a few bugs and sent a few patches. Felt good, I’ll definitly try to keep this up.

And timewise, I might have put in like 8 hours during january for this. That seems reasonable, I’ll start tracking it with letsfreckle as well though, just to make sure it doesnt get to much and also to make sure I actually get something done on that time.

I got frustrated over the overview in time with graphing plugins for redmine. The ones I tried only showed me a growing curve of added tickets, it didnt show any progress or positive feedback. 

I wanted the positive feedback, so I created a quick script which took the atom ticket-list and parsed through it and counted all tickets depending on status:

Just add it to the munin plugin-folder, and it will “just” work. It would be possible to adjust it a bit, so the url comes from the munin plugin config. 

Last week, I realized I needed a quick way to set up logging of incoming udp-messages. My first idea was using netcat which is kind of a swiss army knife when it comes to network data. It worked, but for small scale mostly.

$ nc -l -u -p 4711 » udp-stream.log

GAH! Frustration, google chrome, my thrustworthy companion everyday stopped working today. Segfaulted.

It happened after a reboot, it might have been that I hadnt restarted chrome for a week or two or something like that. The battery went dead which made it hard-reboot. After boot, chrome segfaulted, likely because the version got updated(not entirely sure yet).

I realized that there was a release today in the stable update channel, and figured I might as well try to upgrade to that one(15.0.874.120), the upgrade I had was probably a week or two old. But, no change. I changed the apt cache, and noticed I had google-chrome-stable_15.0.874.106-r107270_i386.deb in there, so I tried to revert to that. No change.

After some googling, I came across this post which seems to indicate a similar problem, and it hinted me to check dmesg. Dmesg tells me its a segfault in ligGL,

[  504.112676] chrome[9171]: segfault at 4 ip a841729c sp b1498600 error 4 in libGL.so.1.2[a83aa000+b4000]

I checked my version of libgl1-mesa-glx, and that was 7.7.1-5, I added backports for squeeze and installed 7.10.3-4~bpo60+1. No change though. Same segmentation fault.

I did some attempts with strace, but its mostly useless(for me) and no obvious place where it happens.

I even tried the beta channel of google chrome(16.0.912.32-r108990 now), but the same error is still there.

Not really sure where to go further, firefox feels like a downgrade when used to chrome imho. :)

Any hints?

I just deployed StatsD together with Graphite and Carbon according to http://codeascraft.etsy.com/2011/02/15/measure-anything-measure-everything/ .

Seems to work nice so far, havent finetuned it so much yet though. Although, I didnt find a decent init-script for StatsD and Debian, so I modified one for RHEL found at https://gist.github.com/1071989 to this Debianized one: https://gist.github.com/1326359 I guess it would also work with ubuntu with minor tweaks(if any).

I’ve been running LAMP-setups throughout the last 12 years or so, but security have always been a big concern. User convenience, simplicity and accessibility have also been big concerns, so security features and a locked down system can not decrease any of theese key points.

This is still a draft, needs to be updated. Consider it as a work in progress.

The setup below is a continous work and will probably be modified, but should be considered as a request-for-comment document. There will likely be lots of improvements possible, and it might even contain security holes that I havent thought about yet.

I expect to keep the following services:

 - ssh/scp/sftp access

 - apache

 - mysql database

 - php

 - outgoing emails

 - use of subversion and git through ssh

 - possibly memcached(to be added later)

Common attack scenarios are

 - sql injections

 - execution of arbitrary phpcode

Goals:

 - Limit successful attacks to a single user account

 - Limit successful attacks so they can not cause much harm to affected user

First and foremost - ssh/scp/sftp

Allow users to ssh and scp into their chrooted home directory. Although, they should be able to use most stuff locally in there, like subversion, git and also access their weblog files. Uploading should be made with scp or preferrably managed with some version control system.

I found this script which sets up a chroot jail where users are sent after successful scp and ssh. Seems to work reasonably well. 

http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/

My biggest worry with it is that its really old. :)

My $APPS-list in it is:

/usr/bin/git-* /bin/chmod /usr/bin/git /usr/bin/file /bin/nc /usr/bin/giftopnm /usr/bin/jpegtopnm /usr/bin/bmptoppm /usr/bin/pnmscale /usr/bin/ppmtojpeg /usr/bin/ppmquant /usr/bin/ppmtogif /usr/bin/pngtopnm /usr/bin/pnmtopng /usr/bin/tail /usr/bin/php /bin/cat /usr/bin/crontab /usr/bin/svnadmin /usr/bin/grep /usr/bin/ssh-keygen /bin/nano /bin/hostname /usr/bin/svn /bin/bash /bin/cp /usr/bin/dircolors /bin/ls /bin/mkdir /bin/mv /bin/rm /bin/rmdir /bin/sh /bin/su /usr/bin/groups /usr/bin/id /usr/bin/rsync /usr/bin/ssh /usr/bin/scp /sbin/unix_chkpwd

This makes users locked into a “fake” system-chroot in /home/jail/. Right now I run multiple users in the same /home/jail, although, they have separate user homedirs in /home/jail/home/user but share the binaries. 

The user-row in /etc/passwd looks like:

user-name:x:1032:1032::/home/jail/home/user-name:/bin/chroot-shell

And this is added to the /etc/sshd_config:

Match Group webuser
ChrootDirectory /home/jail/
AllowTCPForwarding no
X11Forwarding no

Running apache as the real user-user

I’ve been thinking about this a lot, whichever is the best. Now I’m running apache as the real user, within the chroot with help of the mpm-itk module for apache.

This is an example of the virtualhost used. Apache is running as the real jailed user, and documentroot is set as below.

<VirtualHost 127.0.0.1>
        ServerName hostname.domain
	DocumentRoot /home/jail/home/user-name/www/
	AssignUserID user-name user-name
	php_value mysql.default_user db-user-name
	php_value mysql.default_password db-password
	php_value mysql.default_host localhost
    
	php_admin_value 	open_basedir 	/home/jail/home/user-name/	
	php_admin_value	    upload_tmp_dir 	/home/jail/home/user-name/tmp/
	php_admin_value	    session.save_path /home/jail/home/user-name/tmp/
 </VirtualHost>

The virtualhost-config-file can be owned and only readable by root, which means the user can access the environment variables in php with the getenv()-function. This is good, since the user doesnt need to store the database username and password in their homedirectory, makeing it a little bit more protected.

Read more about mpm itk at http://mpm-itk.sesse.net/

Using suhosin to limit PHP

Some things in PHP have so sharp edges that users are more or less expected to do mistakes with them, therefor, I’ve been disabling the following functions:

suhosin.executor.func.blacklist = “register_globals, enable_dl, show_source, system, shell_exec, passthru, exec, popen, proc_open, allow_url_fopen”

TODO:
 - Lots of documentation and clarifications to make
 - Add some example code to verify that its not possible to escape the jail. Would be nice with a thorough testsuite. 

If you see problems somewhere, see good improvements, or have questions, leave a message.