Go 1.7 was released earlier this month, and the thing I’m most excited about is the incorporation of the context package into the Go standard library. Previously it lived in the golang.org/x/net/context package.

With the move, other packages within the standard library can now use it. The net package’s Dialer and os/exec package’s Command can now utilize contexts for easy cancelation. More on this can be found in the Go 1.7 release notes.

Go 1.7 also brings contexts to the net/http package’s Request type for both HTTP clients and servers. Last year I wrote a post about using context.Context with http.Handler when it lived outside the standard library, but Go 1.7 makes things much simpler and thankfully renders all of the approaches from that post obsolete.

A quick recap

I suggest reading my original post for more background, but one of the main uses of context.Context is to pass around request-scoped data. Things like request IDs, authenticated user information, and other data useful for handlers and middleware to examine in the scope of a single HTTP request.

In that post I examined three different approaches for incorporating context into requests. Since contexts are now attached to http.Request values, this is no longer necessary. As long as you’re willing to require at least Go 1.7, it’s now possible to use the standard http.Handler interface and common middleware patterns with context.Context!

The new approach

Recall that the http.Handler interface is defined as:

type Handler interface {
        ServeHTTP(ResponseWriter, *Request)
}

Go 1.7 adds new context-related methods on the *http.Request type.

func (r *Request) Context() context.Context
func (r *Request) WithContext(ctx context.Context) *Request

The Context method returns the current context associated with the request. The WithContext method creates a new Request value with the provided context.

Suppose we want each request to have an associated ID, pulling it from the X-Request-ID HTTP header if present, and generating it if not. We might implement the context functions like this:

type key int
const requestIDKey key = 0

func newContextWithRequestID(ctx context.Context, req *http.Request) context.Context {
    reqID := req.Header.Get("X-Request-ID")
    if reqID == "" {
        reqID = generateRandomID()
    }

    return context.WithValue(ctx, requestIDKey, reqID)
}

func requestIDFromContext(ctx context.Context) string {
    return ctx.Value(requestIDKey).(string)
}

We can implement middleware that derives a new context with a request ID, create a new Request value from it, and pass it onto the next handler in the chain.

func middleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
        ctx := newContextWithRequestID(req.Context(), req)
        next.ServeHTTP(rw, req.WithContext(ctx))
    })
}

The final handler and any middleware lower in the chain have access to all the previously request-scoped data set in middleware above it.

func handler(rw http.ResponseWriter, req *http.Request) {
    reqID := requestIDFromContext(req.Context())
    fmt.Fprintf(rw, "Hello request ID %v\n", reqID)
}

And that’s it! It’s no longer necessary to implement custom context handlers, adapters to standard http.Handler implementations, or hackily wrap http.ResponseWriter. Everything you need is in the standard library, and right there on the *http.Request type.

GSoC comes to an end, so it is time to write a last post about it.

The project

Let’s summarize what I did. You can also see it on Github: https://github.com/openSUSE/osem/commits?author=Ana06

I explained in my last post about the project that I had already changed completely the public schedule of OSEM. Since then I have mainly focused on the admin schedule, the place where the schedule is created. Now it is also possible to have several schedules in the backend before deciding which of them to use. So there is a list of schedules and a switch in every schedule to set that schedule as the selected one. I’ve also changed the appearance and functionality of the admin schedule. This is how it used to look like:

And this is how it looks like now:

As you can see I have integrated it in the admin interface. I’ve used bootstrap while doing so and I have also changed the way events are loaded and scheduled.

I’ve also introduced a Save button, as previously the schedule was saved instantly when dropping and event in a new cell. After clicking Save the page is reload and it is rendered a message to inform that the schedule was correctly saved or the reasons why it was not correctly saved. Another problem I’ve solved is that it was possible to schedule an event at the same time than other event, so things like that could happen:

I’ve also made the schedule times changeable. Previously the schedule started at 9:00 and ended at 20:00 and it was impossible to schedule an event outside this hours range.

Apart from the admin schedule I also add the feature to allow users to have their own schedule by having favourite events:

Nishanth GSoC project interfered few times with mine. It was something great as he pointed out some bugs in my project and I also helped him with the tags in the schedule:

There are some of the things I mentioned that hadn’t been merged yet as they are still being reviewed.

Challenges

I found a little bit tiresome understanding the javascript code previously used for the admin schedule and then changing it almost completely several times. But every time I changed that code I liked it more so it was worthwhile.

Displaying the tags in the schedule properly was not as easy as it seemed at the beginning: osem#1082 and osem#1125. Founding a way to make links inside other link work and to do it with ctrl+click was another little challenge as you can see here: osem#1132 and osem#1134.

Overall experience

Working in an Open Source Project has been much better than I expected (and I had very high expectations ). During the last three months I’ve learnt many things, had really fun and made friends. I would like to thank this amazing summer to all mentors (specially my mentors Christian and Henne) and to the openSUSE community. I also want to thank the TSP program for giving me the chance to attend openSUSE Conference, which was an incredible experience.

I will continue working on Open Source projects and of course I will continue working on OSEM. I also encourage all students reading to apply to GSoC next year and to do it at openSUSE.

It is a little bit late to post pictures of the GSoC welcome package, but I have just found the pictures I took when I received it 3 months ago and I thought that maybe someone likes to see them.

Tools to create multi distribution bootable USB stick got couple of new improvements and features.

live-usb-gui now offers choice of scripts to use, depending in your need you can either use live-fat-stick with vfat partitioned stick or live-grub-stick script which works with any partition format supported by grub2 including vfat, must be used if you have iso bigger than 4G.

live-grub-stick can now create bootable USB from openSUSE installation media isos (standard DVD or NET), difference from --isohybrid option is that the data already on the stick is not touched, the whole iso is available on the stick so you can use the stick to copy it around apart from being able to install from it.

Two new options --suse-persistent(for openSUSE live ISOs) and --ubuntu-persistent(for Ubuntu and clones) are now available, using these options allows live sessions to be persistent over multiple boots, even when used on vfat partition. Again the way it is used does not need change in partition format of the stick, existing data on the stick remains untouched.

Feel free to fork https://github.com/cyberorg/live-fat-stick if you want some more enhancements.

This post has been migrated to my new blog that you can find here:

https://pureooze.com/blog/posts/2016-08-07-what-is-pam/

The last post I did was the start of the Comprehensive Guide To AppArmor which took a look at the basics an administrator or developer needs to know to start creating and deploying AppArmor profiles for a program. In the post I also left a question for the reader regarding AppArmor being used to replace the traditional DAC permissions (but never should!) and how you could use it to remove access to a file from a specific user (rather than a program). However this requires usage of the pam_apparmor module for PAM and due to this, before going into depth with using pam_apparmor, you should make sure you have a grasp of the basics of PAM and its configuration files.

Seriously What Is PAM?

PAM stands for Pluggable Authentication Modules and is used to perform various types of tasks involving authenticaction, authorization and some modification (for example password change). It allows the system administrator to separate the details of authentication tasks from the applications themselves. This allows the policy to not only be generic, it means that the programs do not need to be modified in order to update the policy! An example of PAM usage is controlling login attempts to a shell/GUI interface so that only successful authentication and authorized events are allowed. You could also use PAM to control who can use the su binary to switch identities or control who can use the passwd utility to change passwords.

Overview

When a developer wishes to interact with PAM to let it handle events, they must include libpam which allows communication via the API provided by the library. When PAM sees a new event that it must process, it will look at the relevant configuration files found in /etc/pam.d and determine which modules must be used at certain stages.

PAM is capable of using context to determine what it needs to do, for example the pam_unix.so module has capabilities for the auth and account stack. In the auth stack it checks a username and password combo while in the account stack it will check a users aging and expiration info. This versatility is one of the reasons PAM has been so popular in the UNIX world, it allows for solutions that can be combined to create a generic library to deal with certain type of request.

How Do I Tell A Program Supports PAM?

This is usually pretty easy, you can use ldd to check if libpam is in use:

comp:/home # ldd /usr/sbin/sshd | grep pam
   libpam.so.0 => /lib64/libpam.so.0 (0x02209ddace0105400)

comp:/home # ldd /bin/su | grep pam
   libpam.so.0 => /lib64/libpam.so.0 (0x02999ddace0105400)
   libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x12211ddace1105400)

To read the rest of this post it can be found on my new blog here:

https://pureooze.com/blog/posts/2016-08-07-what-is-pam/

What is PAM? was originally published in Information & Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.