Project homepage for porting of the DICE environment software packages to the LCFG SL7 platform. The Observations section is also (occasionally!) updated. This page was referred to during the SL7Meeting20150106.

2015-02-22 - Alpine gripes

A roundup of two irritating issues with alpine ("updated" to 2.11 but I haven't checked its provenance yet; this is not a release from the original UW maintainers) as I found it on SL7:

The packaged "default" speller hunspell (actually an RPM dependency), seems very poor in its default mode of operation. It's tripping over contractions and all sorts of words it should be able to avoid (and the SL6 speller has no problem with).

2015-02-19 - Display blanking

Investigated one case where a desktop display wouldn't sleep of its own accord (we won't be running a screensaver on the lightdm greeter, but we'd still expect displays to power down on machines that don't sleep). It appears that the X DPMS library was lying to us, or being lied to by the monitor, which claimed to be off (state "3"). Explicitly setting it back on (state 0) caused everything to work again as it should. I couldn't see any root cause, but noticed an EDID error in the system log.

If anyone spots this behaviour on an SL7 machine, just get in touch. I'd rather we found and fixed the problem than had to deploy anything ...

2015-02-18 - Switch flipped!

Apologies for the delay. Customisable login screens are here. Good sources of information on the customisation setup:

$ man lcfg-webpic
<dice/options/webpic.h>

by "default" I've gone with an image of my own creation but I anticipate different sites / labs / machines functions will take advantage of the customisation. Exam PCs and "kiosk" machines, for example, will require custom setups. Remember that these values can all use LCFG template interpolation so it would be straightforward to advertise, for example, which groups of users were permitted to log into a given machine.

Added summary documentation at LoginScreens (authoritative webpic documentation will of course remain with the component).

Notes about dice-getres: Note that there's a possible bootstrapping problem in the use of getres to provide background resolution: if lightdm starts before webpic no background will have been configured, and if webpic starts before the lightdm X session, there's a possibility no resolution can be determined and the component might either fail or fall back to default resolution. We'll see how bad this is in practice before investing any effort to fix it given that, either way, it can be solved with a single reconfigure. This could be related to Bug:847 but, no surprise, more investigation is required. A possible (extreme) solution would be to call webpic as part of the lightdm pre-greeter script, dissolving the webpic component into lightdm.

2015-02-18 - Development meeting talk

Some outline points for today's talk.

Package lists

These are mostly (all?) in place. I'll explain which ones are where, what they're for, how to choose between them.

devel package sets

new rules for devel packages, and how to access them.

Package list inclusion

and why this isn't part of this project, but more of a negotiation with machine managers.

When not to use package lists

Where else to look before resorting to one.

Pending changes to the workflow

This includes streamlined "yummy" list generation and an as-yet undefined process for promoting packages to option sets.

Suggestions?

This has been designed so far towards RAT workflow, but we're not the only ones adding packages.

If we rattle through the above I can talk about some of the side tasks attached to this project.

Alternative window managers: MATE, wmii, fvwm2, and the use of xscreensaver and idle_curiosity.

bash default .rc names: again, this is a discussion first and foremost. already discussed: .brc remains (but .bashrc is supported!)

There is outstanding work attached to X config including .xinit infrastructure (including the screensaver and idle_curiosity) and wmii/fvwm2 default config.

UPDATE: points raised during the talk:

building custom bash:

RAT need to rebuild "our" bash patches for SL7. Or rather include them: I reckon I built the package some time ago...

Subversion

the version mismatch is getting annoying for those of us straddling operating systems. I'll deploy svn-1.7 to SL6 machines after a sys-announce notice period.

Alternative WMs

we should document Gnome → MATE and other alternatives.

Don't forget Cinnamon would be a nice extra alternative in addition to MATE.

Liaise with Alastair about enforcing / encouraging xscreensaver on other desktop managers

I need to export my handy yumtopklist script into the utils directory (I realise now I was hoping to add partitioning by package source, first) this is done.

Other packages: missing the cosignego stack.

2015-02-10 - Towards a usable desktop

Since last update...

Package lists have been tweaked and streamlined, and the rules for their use improved, though this hasn't been heavily tested yet.

The -devel package lists have been moved into the env lists, with instructions to add the packges wherever possible.

Plenty of new "base" packages added to the environment lists as appropriate. This is of course ongoing and we're currently investigating problems with pidgin and SASL/GSSAPI authentication against the Informatics XMPP server (everything else seems to work(!))

The MATE environment has been added as an alternative desktop/WM. fvwm2 is soon to join them.

The lcfg-webpic component has been completed, allowing fully dynamic control of the lightdm greeter's appearance.

A major goal of this development was to allow "unusual" configurations to take advantage of alternative login screens without the effort involved in SL6, for example on lab exam desktops. However in addition to this the dynamic nature of the component (allowing full content control from LCFG, local file or even web if required) means it can have much wider utility, for example displaying lab status or site information.

A last-minute addition to the lcfg-webpic infrastructure is the dice-getres utility which retrieves the resolution of the primary display so that background images can be presented correctly at (theoretically) any resolution.

Progress on the sleep-compatibility of non-standard desktop environments continues as part of the idle_curiosity project.

Numerious other little tweaks here and there...

Also since the last update I'm attempting to change the way effort is reported against this project, so I'm trying to attribute even tenuous, tangential development effort against the SL7 project if at all possible.

2015-01-27 - "Remaining" Tasks

The bulk of the blocking work has now been done, so I ought to recap what remains. Not all of this falls strictly under the remit of this project so I'll link to alternative tracking sources where they become apparent.

Guidance documentation on where to add packages - the new package lists aren't the only / best place to add optional packages.

Actually adding packages! This will be done under guidance from RAT or the documentation as above.

Yummy modifications to support generation of the package lists.

Mechanism to produce rpms lists from yummy files - in consultation with MPU.

~Mechanism for delivery of devel packages: this will depend on the above mechanism.~

~Additional options for window management~

Compatibility of non-standard desktop environments with sleep [this is definitely off-project but part of some ongoing CPD]

2015-01-25 - New environment package lists

I'll talk more about the rationale as part of the next update, but in collaboration with Stephen I've reworked the SL7 environment lists and made plans for the next stage to ease management.

I removed most of the provisional env lists which had been put in place:

REMOVED dice_el7_*.rpms : we don't need to handle any difference between SL7 and EL7 at the DICE layer. Should we require it, I'd propose renaming each SL7 file to its EL7 equivalent and using a simple #include in the SL7 file to manage only the differences.

REMOVED dice_[es]l7_desktop.rpms : we no longer want to have a definition of "desktop" at the package list level. This should live at the header level, allowing each type of machine to pick package lists as appropriate

REMOVED dice_[es]l7_env.rpms : the env list has been heavily abused. Though we do still want a location to add common environment, renaming this gives us a "firebreak" that will hopefully change behaviour by forcing us to choose a more appropriate file.

REMOVED dice_[es]l7_unsupported.rpms : this distinction was only ever for the benefit of COs, so the information can be stored in a comment if it's important. The packages were not treated any differently, and should be filed in an appropriate list if "everywhere" isn't the appropriate destination.

REMOVED dice_[es]l7_base.rpms : the word "base" was confusing as most of these were not "base" RPMs in any sense.

The new structure is pretty simple, partitioned minimally by RPM source (the RAT packages aren't strictly part of this project but it makes sense to list them here):

To some extent the env_user lists are probably going to be underutilised, because there are few packages which don't imply some sort of graphical environment, but it's an important distinction given the massive dependency tree that e.g. X or GNOME entail.

I haven't yet strictly defined what categories of machine pick up which headers, but I had a few use cases in mind. It's clear that "small_server" machines are unlikely to take the user packages, but remote X servers (e.g. the NX service) will have to take at least graphical list. Desktops will typically have the full graphical _and RAT sets. For now I've made it implicit that machines importing _graphical will also import _user, but this isn't set in stone either.

I will talk about the changes required to yummy, and the workflow that will result, next time, but suffice to say that in the long term I do not anticipate anyone handling the env or RAT .rpms files manually in due course: rather we'd simply edit the appropriate yummy source(s).

Oh yes -- I'd heavily encourage COs to read the opening comment sections of each of these headers, which should explain their use entirely (including pointers to alternative files where appropriate). If they're unclear, just get in touch.

20 Nov 2014 - More login ramblings

LightDM still working very well but on occasion something is overriding its permission to launch - the greeter fails with an auth error, leaving you without X for a time. It transpires that actually an RPM reinstall is required to rectify it. More investigation required, obviously we're not managing all of the requisite config files yet. (The error got lost on successful relaunch - I await its reoccurrence).

I also need to check the mechanism by which the previous choice of Window manager is retained - I'm not convinced it's doing it wrong, I just need more information...

I also installed the Cinnamon package set on my desktop so that I have a working analogue to gnome-screensaver. No kerberos renewal support of course.

12 Nov 2014 - Update

Installing with the new Kerberos component was a mixed bag -- failure to type my credentials correctly caused the installer to "fail" and dump me to a prompt, which isn't ideal. I could from there simply run the command which failed, again (helpfully still displayed on on the console above me) and reboot, but it wasn't a great interface. Best alternative isn't clear because infinite loops aren't cool, either...

Installing with lightdm wasn't immediately successful - some interaction with the auth component perhaps (we have to define the lightdm user in localaccounts.h) as a few component "configures" were required to make the display manager spring to life.

09 Nov 2014 - The Display Manager

I've added further notes into the 'Observations' section.

From the inspired suggestion and initial configuration by Chris, we have a working replacement window manager which in comparison is a joy to use and configure. It also looks like we'll be able to use this more safely with lab exams, which was a concern. I have created configuration to replace the default window manager:

As CPD I have written a script which will overlay text onto given images and if I develop it sufficiently I'm going to push for this to be used to display both static OS / login info, and also dynamic status information.

07 Nov 2014 - More notes

I'm now using both the kerberos and the SSSD tests from Inf Unit. They seem to work well but of course I created my host key manually.

I've integrated further notes into the 'Observations' section. Diff will clarify changes.

I've installed an SL7 (hardware) desktop because it's the best way to get to grips with what constitutes the environment. I list several observations below, not all of which come under the scope of this project, or indeed environment, but which I'd prefer not to lose track of. I hope to strike these or link to external trackers if they're resolved or handled elsewhere.

I don't propose to investigate any/all of these - any interested parties please take a look.

"Custom" isn't actually custom in any way, it's just more GNOME options. - actually we still need to work through alternative WM options.

Hitting 'tab' after the username prompt has a high chance of failure. Actually it's invisibly highlighting the session chooser, but with no keyboard way to control the popup menu it's useless. Accordingly, 'Enter'/'Return' don't seem to fail, nor does the 'Next' button.

Personally, I won't be using it. We should still investigate a reasonable alternative.

~/.XDefaults is not read

keychain doesn't seem to upgrade cleanly - password prompt. Maybe I just forgot!? Certainly should be possible to integrate with login password. PAM?

update - having wiped all keychain config I still get a keychain prompt on a gnome-shell login, but I haven't traced where it's coming from. Need to check on a clean login.

Having enabled second monitor (with 'xrandr' invocation) I now suffer the following on my 755: 2014-11-04T09:33:40.126564+00:00 kempt kernel: [317196.611533] gnome-shell[20220]: segfault at 0 ip 00007fcd2269df51 sp 00007fff4d044c50 error 4 in libdricore9.2.5.so.1.0.0[7fcd224d7000+3cf000] which prevents me from logging in. GNOME-classic doesn't help, whereas wmii= works fine. works following a reboot or two. Also worked first time on replacement 780.

Yum config

CO desktops at least ought to have full repos, but:

If we maintained consistent repos on all user-facing machines, users could simply use "yum search" on their desktops rather than relying on pkgsearch.

update been informed this is under review.

we also really ought to make use of yummy as part of RAT packages. update: this will be done alongside env package lists

Console environment

US keyboard by default (locale is OK so will need some investigation). -- now Bug:850

MISSING / Non-functional (no expectation they're working yet, just to stop me banging my head against the same wall twice)

dice/options/office-at.h

dice/options/co-desktop.h

dice/options/chrome.h - I've updated this to include a recent version of Chrome but it requires all of redhat-lsb so I'd like to clear the packages with MPU first.

gnome-screensaver is gone. Better get xscreensaver as it's safer? Or are screensavers old-fashioned and we just need to DPMS the monitor?

07 Oct 2014 - Notes on KDE

For reference, the problem with KDE in SL6 is or was the use of the "akonadi" personal information database (used by core elements of the desktop environment), backed my MySQL. The problem was that there was no way to change the socket path (defaulting to $HOME/....) centrally. This was reported as a bug in 2008 and has now been fixed. Testing also confirms that KDE performs as expected under SL7: /tmp/akonadi* directories are now created. So, the problem was significantly overstated, and in any event resolved!

29 Sep 2014 - Proposal

Following discussion on 24th Sep [link to TDM pending] there were no strong feelings over the future of the dice_sl6_env package list. Consequently RAT are proposing the following structure to the project:

Items in italics were added following the meeting itself.

Prepare tracking page / system for progress of the below:

New env header

Replace the _env package list with a small header containing little more than bash and defenv

24 Sep 2014 - discussion

This project follows the form of previous projects to port the DICE environment to each new DICE platform. For SL5 → SL6 this involved little more than porting the packages on the dice_sl5_env.rpms list, but following internal discussion we feel it's worth checking any assumptions before proceeding. We've identified two main questions, and lots of sub-questions:

1. What is the _env list for?

Following internal discussion the RAT unit identified various categories of package within the list dice_sl6_env.rpms:

bash and defenv

"commodity" requirements, not mandatory for DICE to behave like DICE, just useful on all categories of machine

Core utilities, but maintained by other units, e.g. "=renc="

teaching/research/personal requirements which for whatever reason don't "belong" on the RAT lists

various Perl, Python and other library dependencies, whose dependents on DICE aren't clear

DICE utilities which probably don't belong outwith CO desktops

The header itself suggests that it is to be used for "packages from epel" but this seems to be an incredibly broad criterion for inclusion on all machines (and after considerable MPU efforts to slim down the base install, too).

Some questions:

What do we do with these lists? Can we split the file up, restoring some meaning to the "env" list?

What should RAT do about non-RAT packages?

Can "yummy" help us on SL7?

What is the difference between _env and _unsupported? Are the packages in _env (such as AbobeReader really any more supported than the others?

We really, really don't want Adobe Reader on every single machine. Where do we put this category of package? What is this category?

2. What constitutes "environment"?

Assuming our effectively-mandatory shell bash is part of the environment, it occurs to us that we do we not manage our default (albeit non-mandatory) desktop GNOME environment in the same way. This has historically presumably been because desktop environments didn't need or accept much configuration, but this has changed, and we have the gconf component for basic configuration, too. more questions:

Do we need to configure the environment? Should we be managing anything else?

Is there anyone looking after "user experience", testing e.g. GNOME following a student first-login on SL7?

For example: What happens when KDE (effectively, due to locking problems on AFS) disappears? Is this part of the project?