Several weeks ago I took the plunge and upgraded my work laptop to run Ubuntu 11.10 and after switching to Gnome Shell, all has gone well and I've grown accustomed to the way Gnome 3 works.

One thing that hit me when I initially upgraded was the way the proxy settings are configured and used by Ubuntu 11.10 seemed a bit broken. The "system wide" settings weren't taking effect as they used to in Ubuntu 11.04. After a fair amount of hacking around and changing individual applications to use their own settings instead of the centralize setting, all was well. Until this morning.

This morning was the first time I've used Ubuntu 11.10 to connect to work via the Cisco AnyConnect VPN client. It used to work on 11.04 so I was very surprised to find it didn't work this morning. All attempts to connect failed with...

Note the message at the bottom of the window... "Unable to process response from...". Not very useful at all.

A quick search around Google revealed nothing. I downloaded and re-installed the client. No go. By now, I'd wasted about 30 mins and was now technically late for my shift, so I quickly installed OpenConnect and it worked a treat and worked all day. Performance was a bit poor at times, but I don't know if that was OpenConnect, work or my broadband.

This evening, once I'd finished my shift, I investigated why the AnyConnect client wasn't connecting. Rather than trawl through Google even more, I decided to trace executing the client from the command line...

$ strace /opt/cisco/vpn/bin/vpn connect [my.vpn.servername] 2>/tmp/error.log
Cisco AnyConnect VPN Client (version 2.5.0217) .

Copyright (c) 2004 - 2010 Cisco Systems, Inc.
All Rights Reserved.


  >> state: Disconnected
  >> warning: No profile is available.  Please enter host to "Connect to".
  >> notice: VPN Service is available.
  >> registered with local VPN subsystem.
  >> state: Disconnected
  >> notice: VPN Service is available.
VPN>   >> contacting host (my.vpn.servername) for login information...
  >> notice: Contacting my.vpn.servername.
  >> warning: Unable to process response from my.vpn.servername.
  >> error: Connection attempt failed.  Please try again.
  >> state: Disconnected
VPN> %         

Nothing useful there, as I expected, but what about the strace file? Well, it did have something interesting...

socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 13
connect(13, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) = 0
poll([{fd=13, events=POLLOUT}], 1, 0)   = 1 ([{fd=13, revents=POLLOUT}])
sendto(13, "=*\1\0\0\1\0\0\0\0\0\0\thostname\2uk\6domain"..., 41, MSG_NOSIGNAL, NULL, 0) = 41
poll([{fd=13, events=POLLIN}], 1, 5000) = 1 ([{fd=13, revents=POLLIN}])
ioctl(13, FIONREAD, [100])              = 0

Huh?? It's attempting to resolve the proxy hostname (obfuscated to hostname.uk.domain by me) which means it's trying to connect to the proxy. Why is it trying to connect to my proxy? To try and connect to https://my.vpn.servername.

Sure enough, unsetting the https_proxy environment variable from the command line allowed me to connect using the CLI invocation of the client.

So what about the GUI? Well, as I tend to use my laptop at work more often than not, I decided to just create a wrapper script around /opt/cisco/vpn/bin/vpnui as follows:

$ sudo -i
# mv /opt/cisco/vpn/bin/vpnui{,.orig}
# cat > /opt/cisco/vpn/bin/vpnui
#!/bin/sh
unset https_proxy
/opt/cisco/vpn/bin/vpnui.orig
^d
# chmod +x /opt/cisco/vpn/bin/vpnui
# exit

Now when I start the VPN client via the GUI, it unsets the proxy just for that shell and we're A-for-Away and I can connect. I know I could just disable the proxy configuration and initiate the VPN connect, but once I'm connected to the VPN, I'd need to re-enable it again. Seems like a waste of time to me when I only need the proxy disabled for a moment.

I have no idea what Ubuntu has done with the proxy configuration in 11.10, but all I know it it's far from perfect and I was definitely not expecting it to be the culprit here.

More sad news in the computing world: Dennis Richie passed away this weekend after a long battle against an unspecified illness.

The passing of Dennis Ritchie is not going to get the same attention the passing of Steve Jobs did, which is a shame as I believe Dennis Ritchie contributed more to computing in more people's lives than Steve Jobs ever did, whether people know it or not. I know for certain that I wouldn't be doing my current job had it not been for Dennis Ritchie.

For those who don't know or who aren't quite sure, Wikipedia has a nice biography...

Ritchie was best known as the creator of the C programming language and a key developer of the Unix operating system, and as co-author of the definitive book on C, The C Programming Language, commonly referred to as K&R (in reference to the authors Kernighan and Ritchie).

Ritchie's invention of C and his role in the development of UNIX alongside Ken Thompson has placed him as an important pioneer of modern computing. The C language is still widely used today in application and operating system development, and its influence is seen in most modern programming languages. UNIX has also been influential, establishing concepts and principles that are now precepts of computing.

Who knows is Solaris would ever have happened had Dennis not help develop UNIX.

I think some of the tributes to Dennis have also been good and most of them quite geeky but of them all, I think James Grimmelman's tweet sums it up beautifully...

Dennis Ritchie (1941-2011). His pointer has been cast to void *; his process has terminated with exit code 0.

Rest in Peace Dennis Ritchie.

Well, it's been a week since I implemented my changes to the tagcloud.swf and I've not encountered any problems. I've also been in touch with MustLive who reported the original XSS and HTML Injection issues I mentioned last week and he believes my changes successfully mitigate the HTML Injection issue.

So, with that in mind, I'm pleased to announce HB-Cumulus 1.9 as the latest revision of HB-Cumulus and for a limited time only, it is the ONLY port of WP-Cumulus that is NOT vulnerable to the HTML Injection issue.

I'm in the process of writing up my changes and I'll feed them back to Roy so he can fix WP-Cumulus and in doing so, fix all the other ports where the authors, like Roy, couldn't be bothered to look into this issue themselves. I need to be quick this this though as my trial Flash CS5 license is about to expire

This week an announcement was made on Seclist.org about a XSS and HTML Injection vulnerability in all the plugins that use the original tagcloud.swf from WP-Cumulus (which includes HB-Cumulus).

The XSS vulnerability was fixed a long long time ago in HB-Cumulus - 19 December 2009 to be precise - so if you are running HB-Cumulus 1.4 or earlier, you MUST upgrade.

The HTML Injection issue hasn't and can't be resolved due to the way the plugin works. That said, I'm not sure this is really much of an issue.

In short, the way the tagcloud.swf works is it takes input in the form of a string (as an argument) or from a xml file. The only HTML tag that are used and accepted by the plugin is the <a> tag. This is how the tag cloud knows that to display and link to without actually having to rebuild the Flash file repeatedly.

Now the HTML injection vulnerability basically states that this "feature" allows anyone to set any link they like, which is correct and true. Now this could be used to insert links to malicious sites, but in order for that to happen the "hacker" would have to have control of the HTML page in which the tagcloud.swf is embedded and thus effectively using the tagcloud.swf as it was designed.

This can NOT be used to exploit the security of the site hosting the tagcloud.swf file.

I have whipped up a rebuild of the tagcloud.swf that doesn't stop this issue (I can't else the plugin wouldn't work and everyone would need to recompile the tagcloud.swf everytime they updated a post) but it does limit the effectiveness of the links and by only displaying the links if they link to a domain that is the same as that hosting the tagcloud.swf file.

I'll test this for a couple of days on my own sites (it's in place on this site already) and if I don't spot any problems, I'll release an updated version of HB-Cumulus with this updated file in it.

• Thank you Joyent! - Some very useful contributions made to Illumos by Joyent. Pity Sun wasn't quite so accepting of changes in the past. There are some really useful changes here that really should be in Solaris. Who knows, maybe they'll be incorporated one day.
• The Cloud is not a Silver Bullet – stu.mp - A great explanation as to why the recent Amazon outage affected so many sites. In short: bad planning by the sites that used Amazon's services.
• The Usability of Passwords (by @baekdal) #tips - A good discussion on the use of easy to remember passwords being as secure as complex passwords without the unnecessary agro of trying to type the complex passwords.
• End of Feature Notices for Oracle Solaris 11 Express - Take note of this list of EOLd features when considering upgrading to Solaris 11 Express, especially for older SPARC machines.
• The Observation Deck » KVM on illumos - This is pretty impressive and something I think would be great in Solaris itself. I've downloaded the ISO. Time to get playing.

Many applications, like Oracle 11g, need larger than default process values for things like stack size and file descriptors and normally document it in their installation guides. Oracle 11gR2 is very vague about how to configure the "shell limits" and instead concentrates on telling you what it expects and how you can check the current values using ulimit(1).

Update - 9 March 2012: This post has been updated to reflect a correction in behaviour introduced in patch 146654-01 (SPARC) and/or 146670-02 (SPARC) and 146655-01 (x86) and/or 146671-02 (x86). These patches fix a problem (CR 6911915) where "basic" and "privilege" /etc/project settings we not being set correctly and thus "privileged" /etc/project settings were showing as soft limits in ulimit(1).

Using ulimit(1)

Most sysadmins turn to using ulimit(1) to set the appropriate values by adding something like the following to the system-wide /etc/profile or the specific application user's profile (the comments are mine):

# Set stack size to unlimited
ulimit -s unlimited
# Set maximum file descriptors to unlimited
ulimit -n unlimited

For the curious, these are the defaults on a Solaris 10 8/11 system (which includes the above patches) using the zsh shell as it shows the ulimit(1) options:

$ ulimit -Sa
-t: cpu time (seconds)         unlimited
-f: file size (blocks)         unlimited
-d: data seg size (kbytes)     unlimited
-s: stack size (kbytes)        8192
-c: core file size (blocks)    0
-n: file descriptors           256
-v: virtual memory size (kb)   unlimited
$ 
$ ulimit -Ha
-t: cpu time (seconds)         unlimited
-f: file size (blocks)         unlimited
-d: data seg size (kbytes)     unlimited
-s: stack size (kbytes)        unlimited
-c: core file size (blocks)    0
-n: file descriptors           65536
-v: virtual memory size (kb)   unlimited

This is all well and good and works. There are however a few disadvantages with this approach:

1. It adds another location to configure settings for your application which you may forget about.
2. If placed in the /etc/profile, these limits will affect ALL users and processes on the system unless you add in various checks in your /etc/profile to try and limit the users this applies to.
3. This is an antiquated method of setting these settings. Projects are the way to go. You're already using projects to set the semaphore and shared memory settings (here in the Oracle 11gR2 docs), so why not use this same functionality for setting these shell limits?

Using Projects

So how do you do it in projects?

Each of these ulimit(1) options equates to a corresponding project control:

So it's just a matter of running the appropriate projmod(1) command to set the desired value.

For example to set the stack size to 32768 kb use:

# projmod -s -K "process.max-stack-size=(privileged,32MB,deny)" user.oracle

To set the file descriptors to 1024 use:

# projmod -s -K "process.max-file-descriptor=(privileged,1024,deny)" user.oracle

Or set both at the same time using:

# projmod -s -K "process.max-stack-size=(privileged,32768kb,deny);process.max-file-descriptor=(privileged,1024,deny)" user.oracle

Note: If you don't already have a user.oracle project, you'll need to use projadd(1M). See its man page for usage details. You can also use "friendly" values as I have done above.

Keep in mind that "basic" /etc/project settings equate to soft limits within ulimit(1) and "privileged" /etc/project settings equate to hard limits within ulimit(1). ulimit(1)'s default output is also to display the soft limits.

Your changes will only take effect on new processes created by that user, except those created as children of processes that were started before you made the change. If you can't stop a process you can use newtask(1) to assign the running process a new task, or use prctl(1) to change these values on running processes. See the respective man pages for details on how to do this.

You can verify your changes have taken effect using ulimit(1), run as the oracle user in a new shell started after the project modifications:

$ ulimit -Ha
-t: cpu time (seconds)         unlimited
-f: file size (blocks)         unlimited
-d: data seg size (kbytes)     unlimited
-s: stack size (kbytes)        32768
-c: core file size (blocks)    0
-n: file descriptors           1024
-v: virtual memory size (kb)   unlimited
$

... or prctl(1) run as the oracle user in a new shell started after the project modifications...

$ prctl -n process.max-stack-size -t privileged  $$ 
process: 13152: zsh
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
process.max-stack-size
        privileged      32.0MB      -   deny                                 -
$ prctl -n process.max-file-descriptor -t privileged  $$ 
process: 13152: zsh
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
process.max-file-descriptor
        privileged      1.02K       -   deny                                 -
$

Note, the soft limits will not have changed as we set our settings using the "privileged" type:

$ ulimit -Sa
-t: cpu time (seconds)         unlimited
-f: file size (blocks)         unlimited
-d: data seg size (kbytes)     unlimited
-s: stack size (kbytes)        8192
-c: core file size (blocks)    0
-n: file descriptors           256
-v: virtual memory size (kb)   unlimited
$
$ prctl -n process.max-stack-size -t basic  $$     
process: 13152: -zsh
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
process.max-stack-size
        basic           8.00MB      -   deny                             13152
$ prctl -n process.max-file-descriptor -t basic  $$ 
process: 13152: -zsh
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
process.max-file-descriptor
        basic             256       -   deny                             13152
$

If you set "basic" /etc/project settings, the "privileged" and thus hard limits will not change.

Setting Unlimited

One question that often comes up is...

How do I set one of these values to 'unlimited' via projects like I can using ulimit?

This isn't actually made very clear in the Resource Management documentation. You can't use the word "unlimited" as the resource controls have no concept of "unlimited". Instead, you just need to set the value to the maximum allowed system value.

So what is the maximum allowed system value? Well you could dig out the tunable parameters guide and trawl through it, but the easiest method is to use prctl(1) to query the "system" value for the appropriate resource control for your current shell.

For example, to see the maximum stack size, use:

$ prctl -P -t system -n process.max-stack-size $$
process: 13152: zsh
process.max-stack-size system 9223372036854775807 max deny -
$

You can then use this value in your projmod(1) command...

# projmod -s -K "process.max-stack-size=(privileged,9223372036854775807,deny)" user.oracle

... and then verify it as the oracle user...

# su - oracle -c "ulimit -Hs"
Oracle Corporation	SunOS 5.10	Generic Patch	January 2005
unlimited
#

You can find further details on using projects for resource management in the Resource Management section of the System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones guide.

Today's XKCD, "Password Strength"...

... has been a topic that has been on my mind for a while and I'm quite pleased to see it come up in a comic. Ever since I read this interesting article on The Usability of Passwords (it's an old story but it re-emerged or at least fell into my scope of reading in May this year) I'm finding myself using simple phrases more and more as they're more secure and easier to remember. I can't use phrases for every site and host I log into as far too many sites still seem to think complexity = security, but I do where I can.

I really hope this cartoon, and this research from this paper (PDF) by Philip Inglesant and M. Angela Sasse from University College London, (which concludes that we've trained our users to use passwords that computers can easily guess and humans can't possibly remember) will make sysadmins and website developers realise that dogmatic password policies around complexity are more likely to be detrimental to security than advantageous.

Solaris zones are a great invention and a brilliant use of a system's resources, but there's always been one little niggle that has annoyed sysadmins and application vendors:

How do you determine if you are in a zone or not and if you are, what is its type?

There are a number of methods I've seen being employed from people loopback mounting a file from the global zone which contains this information to making assumptions based on the output of commands like ps(1) or zonename(1) but these are all "hacks" which require some foresight by the admin and doesn't always answer the "what type of zone" question.

Well, I can say there is an officially supported method that you can use... the pkgcond(1M) command.

Have a look at this:

$ pkgcond -n is_what /
can_add_driver=0
can_remove_driver=0
can_update_driver=0
is_alternative_root=0
is_boot_environment=0
is_diskless_client=0
is_global_zone=1
is_mounted_miniroot=0
is_netinstall_image=0
is_nonglobal_zone=0
is_path_writable=1
is_running_system=1
is_sparse_root_nonglobal_zone=0
is_whole_root_nonglobal_zone=0
$

I bet you can guess straight away where I ran this command

You can of course query just one parameter:

$ pkgcond -n is_sparse_root_nonglobal_zone /
$ echo $?
0
$

Knowing this little titbit of information, you can easily incorporate it into you admin or application scripts in the quiet confidence that you will get the exact answer you want without having to cobble together some fancy script or other methods to determine if you are in a non-global zone or not and if you are, its type.

After a lot of talking - we've been talking about moving off Trac for a very very long time - and a lot of hair pulling and generally bodging things together to keep Trac up and running (thanks Mike and Chris), Habari has finally made the leap across to GitHub.

Great work guys, with special thanks going to Owen for a) finally taking the bull by the horns and ending all the talking about taking action and actually taking action and b) for spending a lot of his time performing the migration of the main Habari repos and currently open tickets from SVN/Trac to GitHub, here and here respectively.

It's been just over a week now since the move took place and other than a few teething problems (I've made a few mistakes getting to grasp with git, GitHub and submodules) everything seems to be going well. More thanks to the guys on #habari (IRC) for helping us git noobs with our questions problems too.

If you're interested in contributing to Habari and are familiar with git and GitHub, you should be right at home: you can now use the same clone, change and pull request method as you use for other GitHub projects. For those who aren't too familiar, you can find a procedure here (this link may move, but I'll hopefully remember to update this post when it does).

This should make contributing to Habari soooo much easier, should ease administration of the code base and tickets so more time can be spent on coding rather than holding the house of cards up and this should also give Habari more exposure.

Why don't you spend the day investigating how ready you are for IPv6 (you WILL have to embrace it sooner rather than later) and take part in the 24 hour "test flight" being offered by some of the big organisations like Google, Facebook and Yahoo!.

You can find more details on taking part and testing at http://worldipv6day.org/.

I'm eager to take part and actually start using IPv6, but sadly my ISP seems dead keen on living in the dark ages and doesn't seem to want to offer IPv6 to its customers just yet.