Writing modern C

Posted January 10, 2016 by squinney
Categories: Uncategorized

For the v4 LCFG client project I’ve been writing lots of C. To get my C knowledge up to scratch I’ve been consulting many books of varying vintages which leads to quite a mixture of coding styles. I’m quite keen to create code which is concerned “good” according to modern coding standards but I also want to ensure it will compile on a wide range of Unix-like systems, that seems to mean right now that the standard to aim for is C99. I recently came across an interesting article titled "How to C (as of 2016)" which gives a good summary of many important topics to consider. I’ve already been following many of the suggestions but there are also quite a few which are totally new to me. I’m not sure I agree with all of them (e.g. not using char) but I shall definitely be applying some of them.

Security awareness

Posted November 20, 2015 by squinney
Categories: Uncategorized

I recently came across a series of short blog posts from the SANS Securing the Human site on the topic of Security Awareness. I found them to be quite interesting and thought provoking. If you’re interested in what can be done to improve the security of an organization I’d recommend these as a good starting point:

  1. The 4 Ws to Awareness Success
  2. The Why in Effective Awareness Programs
  3. The Who in Effective Awareness Training
  4. The What in Effective Awareness Training
  5. The How in Effective Awareness Training

LCFG XML Profile changes

Posted August 20, 2015 by squinney
Categories: Uncategorized

Tags:

As part of the LCFG v4 client project I am working on converting the XML profile parsing over to using the libxml2 library. Recent testing has revealed a number of shortcomings in the way the LCFG XML profiles are generated which break parsers which are stricter than the old W3C code upon which the current client is based. In particular the encoding of entities has always been done in a style which is more suitable for HTML than XML. There is really only a small set of characters that must be encoded for XML, those are: single-quote, double-quote, left-angle-bracket, right-angle-bracket and ampersand (in some contexts the set can be even smaller). The new XML parser was barfing on unknown named entities which would be supported by a typical web browser. It is possible to educate an XML parser about these entities but it’s not really necessary. A better solution is to emit XML which is utf-8 compliant which avoids the needs for additional encoding. Alongside this problem of encoding more than was necessary the server was not encoding significant whitespace, e.g. newlines, carriage returns and tabs. By default a standards compliant XML parser will ignore such whitespace. An LCFG resource might well contain such whitespace so it was necessary to add encoding support to the server. In the process of making these changes to the LCFG::Server::Profile::XML module I merged all the calls to the encoder into a call to a single new EncodeData subroutine so that it is now trivial to tweak the encoding as required. These changes will be going out in version 3.3.0 of the LCFG-Compiler package in the next stable release. As always, please let us know if these changes break anything.

MooX::HandlesVia and roles

Posted August 20, 2015 by squinney
Categories: Uncategorized

Tags:

I’ve been using Moo for Perl object-oriented programming for a while now. It’s really quite nice, it certainly does everything I need and it’s much lighter than Moose.

Whilst working on the LCFG v4 client project I recently came across a problem with the MooX::HandlesVia module when used in conjunction with roles. I thought it worth blogging about if only to save some other pour soul from a lot of head scratching (probably me in 6 months time).

If a class is composed of more than one role and each role uses the MooX::HandlesVia module, for example:

{
    package SJQ::Role::Foo;
    use Moo::Role;
    use MooX::HandlesVia;
}

{
    package SJQ::Role::Bar;
    use Moo::Role;
    use MooX::HandlesVia;
}

{
    package SJQ::Baz;
    use Moo;

    with 'SJQ::Role::Foo','SJQ::Role::Bar';

    use namespace::clean;
}

my $test = SJQ::Baz->new();

It fails and the following error message is generated:

Due to a method name conflict between roles 'SJQ::Role::Bar and
SJQ::Role::Foo', the method 'has' must be implemented by 'SJQ::Baz'
at /usr/share/perl5/vendor_perl/Role/Tiny.pm line 215.

It appears that MooX::HandlesVia provides its own replacement has method and this causes a problem when namespace::clean is also used.

The solution is to apply the roles separately, it’s perfectly allowable to call the with method several times. For example:

{
    package SJQ::Baz;
    use Moo;

    with 'SJQ::Role::Foo';
    with 'SJQ::Role::Bar';

    use namespace::clean;
}

PostgreSQL new features

Posted June 10, 2015 by squinney
Categories: Uncategorized

It looks like PostgreSQL 9.4 has some really interesting new features. Today I came across a blog post by 2ndquadrant demonstrating the WITHIN GROUP and FILTER clauses. I don’t think I’ve entirely got my head round the purpose of WITHIN GROUP yet, I suspect I need a couple of good real-world examples. The FILTER clause looks very handy though, I’m sure I’ll be using that when I get the chance.

LCFG::Component environment plugins

Posted January 5, 2015 by squinney
Categories: Uncategorized

Tags:

Version 1.13.0 the Perl version of the ngeneric framework (LCFG::Component) provides an all-new environment initialisation system for component methods. This has support for plugins which mean it is fully extensible.

There is a new InitializeEnvironment method which is called for most standard methods which are accessible via om (including configure, start, restart, stop, run, and logrotate). The method can also be called from any additional methods you have added to your own components, the method needs access to the resources so it must be called after a call to LoadProfile or LoadStatus.

There are currently two plugins – a very simple one which can be used to set values for environment variables before the method is called and a more complex one that can do the equivalent of kinit and aklog to acquire Kerberos credentials and AFS tokens.

For full details see the LCFG wiki.

Moo and Type::Tiny

Posted December 14, 2014 by squinney
Categories: Uncategorized

Tags: ,

At the start of 2014 I was working on a project to further improve the LCFG client. When I hit problems with Moose and its memory usage I discovered the excellent Moo framework which provides all the nice bits but is much less heavyweight. As part of the Perl Advent Calendar for 2014 someone has written a great introductory article on using Moo along with Type::Tiny. I’ve learnt a few things, I particularly like the idea of a “type library” as a good way to organize all the local types.

LCFG::Build::Skeleton changes

Posted December 8, 2014 by squinney
Categories: Uncategorized

Tags: ,

At the LCFG Annual Review meeting held last week one topic which was discussed was the idea of all Perl based LCFG components being implemented as modules with the component script just being a very thin wrapper which loads the module and calls the dispatch method. This has been our recommended coding style for quite a while now and we use this approach for many of the core components.

During the discussion I realised that the lcfg-skeleton tool which is used to create the outline directory structure for new projects does not support this way of working. To make it really easy to create new Perl-based components which follow recommended best-practice I have consequently updated LCFG-Build-Skeleton. The new version 0.4.1 creates a module file (e.g. lib/LCFG/Component/Foo.pm), the necessary CMake file and also tweaks the specfile appropriately. This will be in the stable release on Thursday 18th December or you can grab it from CPAN now.

LCFG authorization

Posted December 3, 2014 by squinney
Categories: Uncategorized

Tags:

The authorization of LCFG component methods (which are called using the om command) is typically done using the LCFG::Authorize module. This is limited to checking usernames and membership of groups managed in LCFG.

In Informatics we have for a long-time used a different module – DICE::Authorize – which extends this to also checking membership of a netgroup. Recently we discovered some problems with our implementation of this functionality which make it very inflexible. We have been connecting directly to the LDAP server and doing the lookup based on hardcoded information in the module. As this really just boils down to checking membership of a netgroup this can clearly be done more simply by calling the innetgr function. This will work via the standard NS framework so will handle LDAP, NIS or whatever is required. The necessary details are then only stored in the standard location and not embedded into the code.

Rather than just rewrite the DICE::Authorize module I took the chance to move the functionality to the LCFG layer, so we now have LCFG::Authorize::NetGroups. This nicely sub-classes the standard module so that if the user is not a member of a netgroup the other checks are then carried out. This is much better code reuse, previously we had two distinct implementations of the basic checks.

Having a new implementation of the authorization module is also handy for dealing with the transition stage. We can keep the old one around so that if a problem is discovered with the new code we can quickly switch back to the old code.

I also took the chance to improve the documentation of the authorization framework so if you’re still running om as root now is a good time to improve things!

Sub-classing LCFG components

Posted December 3, 2014 by squinney
Categories: Uncategorized

Tags:

One topic that often comes up in discussions about how to make things easier for LCFG component authors is the idea of sub-classing.

Although I had never tried it I had always assumed this was possible. Recently whilst looking through the LCFG::Component code I noticed that the list of methods are looked up in the symbol table for the module:

    my $mtable = {};
    for my $method ( ( keys %LCFG::Component:: ),
        ( eval 'keys %' . ref($self) . q{::} ) )
    {
        if ( $method =~ m/^method_(.*)/i ) {
            $mtable->{ lc $1 } = $method;
        }
    }
    $self->{_METHOD} = lc $_METHOD;
    my $_FUNCTION = $mtable->{ $self->{_METHOD} };

So, this will work if your method comes from LCFG::Component or LCFG::Component::Foo but it wouldn’t work if you have a sub-class of Foo. You would potentially miss out on methods which are only in Foo (or have to copy/paste them into your sub-class).

Not only does this make sub-classing tricky it also involves a horrid string eval. There had to be a better way. Thankfully I was already aware of the Class::Inspector module which can do the necessary. This module is widely used by projects such as DBIx::Class and Catalyst so is likely to be reliable. It has a handy methods method which does what we need:

    my $_FUNCTION;
    my $public_methods = Class::Inspector->methods( ref($self), 'public' );
    for my $method (@{$public_methods}) {
        if ( $method =~ m/^Method_(\Q$_METHOD\E)$/i ) {
            $_FUNCTION = $method;
            $_METHOD = $1;
            last;
        }
    }

Much nicer code and a tad more efficient. Now the LCFG component Perl modules are properly sub-classable.