SL7DICEEnvironment < DICE < TWiki https://wiki.inf.ed.ac.uk/DICE/SL7DICEEnvironment

TWiki > DICE Web > ResearchAndTeachingUnit > SL7DICEEnvironment (04 Mar 2015, GrahamDutton) CompProj:311 - SL7 DICE Environment

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.

CompProj:311 - SL7 DICE Environment 2015-02-22 - Alpine gripes 2015-02-19 - Display blanking 2015-02-18 - Switch flipped! 2015-02-18 - Development meeting talk 2015-02-10 - Towards a usable desktop 2015-01-27 - "Remaining" Tasks 2015-01-25 - New environment package lists 20 Nov 2014 - More login ramblings 12 Nov 2014 - Update 09 Nov 2014 - The Display Manager 07 Nov 2014 - More notes 04 Nov 2014 — Observations on SL7 so far 07 Oct 2014 - Notes on KDE 29 Sep 2014 - Proposal 24 Sep 2014 - discussion 1. What is the _env list for? 2. What constitutes "environment"?

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).

attempts to open links in my web browser of choice (a custom w3m wrapper) fail because apparently the $HOME in my mailcap file (alpine uses mailcap's text/html entry) isn't being evaluated any more. Easily fixed but a strange change of behaviour.

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

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

1 of 8 02/11/16 18:17 SL7DICEEnvironment < DICE < TWiki https://wiki.inf.ed.ac.uk/DICE/SL7DICEEnvironment

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.

Login screen: lcfg-webpic and included tools rasterize.js, getres update: documented in LoginScreens 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...

2 of 8 02/11/16 18:17 SL7DICEEnvironment < DICE < TWiki https://wiki.inf.ed.ac.uk/DICE/SL7DICEEnvironment

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.

3 of 8 02/11/16 18:17 SL7DICEEnvironment < DICE < TWiki https://wiki.inf.ed.ac.uk/DICE/SL7DICEEnvironment

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):

RPM source All Machines packages for Packages for General purpose / packager interactive use interactive graphical Research / Teaching use host Informatics dice_sl7_env_common dice_sl7_env_user dice_sl7_env_graphical dice_sl7_rat

SL, EPEL dice_sl7x_env_common dice_sl7x_env_user dice_sl7x_env_graphical dice_sl7x_rat_updates

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

My new SL7 test machine is appropriately named bewilderment. I'd encourage other COs to examine its configuration for comparison / debugging / comment / etc.

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:

4 of 8 02/11/16 18:17 SL7DICEEnvironment < DICE < TWiki https://wiki.inf.ed.ac.uk/DICE/SL7DICEEnvironment

#define DICE_OPTIONS_USE_LIGHTDM #include !file.v_ldmbg mSET(/path/to/background/file)

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.

04 Nov 2014 — Observations on SL7 so far

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.

Installation kdcregister only gives you one shot: http://blog.inf.ed.ac.uk/toby/2014/11/13/changes-to-kdcregister/ lightdm doesn't work until after some(?) component runs pam/auth component fixes solved this. client.c

gdm / greeter / LOGIN SCREEN - obsoleted by lightdm. very poor indeed, usability wise. We should lose the 'lock' screen if we can. Mainly because it's stupid, will have users attempting to swipe the screen, etc. But also because you can no longer see at a glance the difference between logged-out and locked. If not: Users must at least be informed of status, and that they can remove 'lock' screen via keypress. are there keyboard shortcuts for session chooser and accessibility options? Frequently find login screen hangs after username entry; Ctrl-Alt-Backspace fixes it. "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. No real certainty of behaviour on hitting return; lots of visible passwords, failed logins.

Boot process Wrong terminal mode for GRUB update: on some hardware only - weird stretching. Pretty minor unless we have to rely on it for something! It's possible for an updaterpms-triggered reboot to finish after login has completed. update: possibly fixed, haven't tested recently

Default Graphical Environment: update: alternative options to be documented GNOME shell: terrible usability IMHO but that's pretty subjective. 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.

5 of 8 02/11/16 18:17 SL7DICEEnvironment < DICE < TWiki https://wiki.inf.ed.ac.uk/DICE/SL7DICEEnvironment

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?

PACKAGES I'VE ALREADY FELT THE NEED TO INSTALL screen, w3m, finger, whois wmii (unsupported; I've built this from my sources) nmap (COs perhaps?) wireshark (COs; available through cppopts; works)

MORE NOTES ON PACKAGES subversion - we'll need to upgrade svn on DICE to 1.7 to allow cross-platform work. xv no longer builds, lots of warnings/errors: let's go for feh. firefox needs SPNEGO configuration (it works when set manually, though) pidgin builds and functions fine except for our own XMPP server!

jabber: Error is -7 : SASL(-7): invalid parameter supplied: Parameter error in client.c near line 961 connection: Connection error on 0x1c95140 (reason: 3 description: SASL error: SASL(-7): invalid parameter supplied: Parameter erro

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.

1. Prepare tracking page / system for progress of the below: 2. New env header 1. Replace the _env package list with a small header containing little more than bash and defenv 2. Port all packages in this new header 3. Find an appropriate place for anything that's not Environment 1. Porting packages if easy; delegate to responsible unit if not. 2. Incorporate the "unsupported" list into the new system 3. Port trivial packages; notify owners of non-trivial packages. 4. Propose some other mechanism for packages / configurations that don't fit anywhere else / above 5. Propose package-options system, analogous to RAT packages, including self-built ones. 4. Do Something about our graphical environment:

6 of 8 02/11/16 18:17 SL7DICEEnvironment < DICE < TWiki https://wiki.inf.ed.ac.uk/DICE/SL7DICEEnvironment

1. seek confirmation from other units as to what the default environment should actually look like 2. specify environmental requirements and settings within our new environment header if they are required. 3. specifics: 1. what will our default be? GNOME3? Cinnamon? GNOME2.something? 2. Which of the alternatives (and above) will we provide? 3. What will happen to KDE? 4. Figure out what typical user logins might look like. 5. Propose project to cover lab exam environment, if it's not covered by SL7 RAT desktop.

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 LaTeX environment 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?

-- GrahamDutton - begun 24 Sep 2014

Topic revision: r22 - 04 Mar 2015 - 10:38:22 - GrahamDutton

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.

7 of 8 02/11/16 18:17 SL7DICEEnvironment < DICE < TWiki https://wiki.inf.ed.ac.uk/DICE/SL7DICEEnvironment

Ideas, requests, problems regarding TWiki? Send feedback This Wiki uses Cookies

8 of 8 02/11/16 18:17