GDM Banner Message display issue
Hi, I'm working to deploy SL7 workstations in the Govt arena. Policy dictates a legal banner be displayed (e.g. dconf/gsettings org.gnome.login-screen / banner-message-text). I'm having serious trouble displaying the banner in a readable format on a 24" panel display. I'm hoping someone here might have some advice. Here's some background...When designing the deployment, I was using a VirtualBox vm as my lab, I use a PXEboot/kickstart template to manage the provisioning and make it repeatable, and use puppet for configuration management. After manually installing the guest additions, and applying the dconf settings (using puppet for this), the banner looks great inside the guest. I can scale the screen and the banner appears nicely above the username field. The message box even has a nice scroll bar to allow the user to read the whole message before login. Depending on the window size, the message may also appear in a column to the left of the username field. Transfer the kickstart and puppet driven config over to real desktops with 24" screens and the banner message displays in a column from top to bottom, centered on the screen and overlays the username field... No scroll bars. It's pretty darn ugly. I've been scouring the Gnome lists and docs to try and find something relevant with no lock. Is there anyway I can control where/how this message appears on the display? Thanks for any thoughts! Kindly, Sean P.S. If it would be helpful, I can provide a screenshot of the VM, but I don't think I can screenshot the real desktop screen.
Re: GDM Banner Message display issue
Amazing... Your banner works fine. I have scrapped the banner I was using and gone with exactly what's in our /etc/issue file, and it works too. I can't say what the issue was, but I've got to deliver a couple of these systems today so we'll go with what works. On a side note, I did find that since the default umask is 027, when Puppet runs dconf update, the /etc/dconf/db/gdm file has 640 permissions and the gdm user can not read it, so settings were not being applied as desired when puppet makes changes. So that confused the issue even more. I'm not sure how I'll resolve that yet, but for these first couple of systems I will manually set the mode on that file. Thanks for your help!
Re: Vbox with new Kernel vers. 3.10.0-327.3.1(SL7.1)
Hi, I was out for holiday last week and came back to my SL 7.1 desktop needing a slew of updates. I had been running VirtualBox-5.0-5.0.10_104061_el7-1.x86_64 against kernel-3.10.0-229.14.1.el7.x86_64 with out issue. After installing the latest kernel mentioned by Etienne, and attempting to rebuild the vboxdrv modules, I had similar failures. Afterward, I attempted to upgrade to VirtualBox-5.0-5.0.12_104815_el7-1.x86_64, I discovered the libdevmapper issue noted in the previous post which prevented the newer version from installing. It seems that there is a VirtualBox bug filed against the EL7.2 3.10.0-327 kernel noted here: https://www.virtualbox.org/ticket/14866 which may be causing the issues you are encountering. Unfortunately, the testing build for EL7: https://www.virtualbox.org/download/testcase/VirtualBox-5.0-5.0.11_104721_el7-1.x86_64.rpm, does not install due to the same libdevmapper issue. I had hoped maybe the devmapper issue was introduced in builds between the latest testbuild and the release build for 5.0.12, no such luck. I have device-mapper-libs-1.02.93-3.el7_1.1.x86_64 installed, but it seems that the VirtualBox package is calling for device-mapper-libs-1.02.97, which doesn't seem to be available for SL7. The CentOS and Oracle Linux public yum repo's latest version is device-mapper-libs-1.02.107-5.el7.x86_64. Is that in the pipeline for release to SL7 soon? Thanks!
Re: Vbox with new Kernel vers. 3.10.0-327.3.1(SL7.1)
On Tue, 29 Dec 2015 01:08:54 -0800, Akemi Yagi wrote: >> Is that in the pipeline for release to SL7 soon? > >device-mapper-libs-1.02.107-5.el7 (part of the lvm2-2.02.130-5.el7 >package) was released in RHEL 7.2: > >https://rhn.redhat.com/errata/RHBA-2015-2147.html > >So, it will be in SL 7.2. > >SL 7.2 Alpha released about a week ago includes this version of >device-mapper-libs. If you need it now, you can find it here: > >http://ftp.scientificlinux.org/linux/scientific/7rolling/x86_64/ > >Akemi Akemi, Thanks for this, it did not occur to me that this was all related to the 7.2 release. There were notes I saw about the 3.10.0-327 kernel being the 7.2 release kernel, but then my system isn't 7.2 and has this kernel so I made an incorrect assumption there.
Re: a year later - CERN move to Centos - what are we doing?
I would guess Konstantin is bumping up against PackageKit locking everything yum related up. This happens to me on occasion when I'm remotely administrating EL7 desktops.
Re: Kickstart / PXE / Cobbler / Ansible
Apologies for being late to this discussion... I have some history and experience with Kickstart and Cobbler through Red Hat Satellite Server. The current version of Satellite Server (6) is no longer using Cobbler. Instead they have moved into using Foreman+Puppet [1] and Katello+Pulp+Candlepin [2] to comprise the Satellite Server Suite. This is a fairly complex set of tools for system lifecycle, configuration, repository, and subscription/license management. In my current role and previous places of employment, we used the Foreman+Puppet alone. One of the beauties of Foreman is that it's interface with Config-Management automation tools is that it's plugin driven. The Default is Puppet, but Foreman also already works with other tools like Chef and Salt. There is ongoing development of user stories for the integration of Ansible, and I believe early version of the plugins have been published. [1] http://theforeman.org [2] http://katello.org Foreman provides an orchestration front end for multi-platform Network or Custom Boot ISO based provisioning. Foreman can be integrated with ISC or MS DHCP and DNS to orchestrate the creating of leases and dns records as a new system is provisioned. Foreman supports EL kickstart, Debian preseed, and Solaris jumpstart for network provisioning, I have personally used kickstarts and jumpstarts (even for sparc) from Foreman. The provisioning profiles can be templated using ERB (ruby) to be made dynamic based on data that surrounds the new system (e.g. physical location, subnet, domain, OS, version, system owner, etc.). Foreman also integrates with Docker, Digital Ocean, OpenStack, oVirt, Xen, EC2, Rackspace, VMWare, Google Compute and LibVirt for cloud/virtual provisioning. I highly recommend anyone who might be interested in automated provisioning to take a look at the tool set. After 20 years of Solaris/AIX/HPUX and Linux system admining, I'm now a puppet guy, but I came to be so through what Foreman presented. The combination of these products revolutionizes the way I look at system deployment and ongoing management. The Foreman Team has produced a lot of nice Youtube videos and Google Hangout presentations covering the features and capabilities of the product. Like this mailing list, they are a very helpful bunch as well. In my current role today, we're producing a Foreman/Puppet based solution for the directorates in the govt. agency I work for. We expect to reduce the labor time in provisioning, configuring and enforcing policy compliance of Linux Desktops and Servers by a ratio of about 6:1. In most of these directorates today, system admins spend about 4-8 hours building and configuring a policy compliant linux systems...each uses their own methods. Foreman reduces the provisioning part to a few minutes, Puppet reduces the compliance part by hours. This opens the door for those admins to stop fighting compliance issues, even future remediation, as Puppet will continually enforce the policy as well as audit and report the actions it takes (reports presented nicely in Foreman), so that they can do the real work of supporting their customer's needs. Hope this helps!
Troubles updating from 7.1 to 7.2...
Greetings, I posted a while back about conflicts that came up under 7.1 when the kernel for 7.2 was dropped into the 7.1 security repo. I had issues with VirtualBox kernel modules and dependencies to packages not backported from 7.2 into 7.1. Since that time I had avoided doing kernel updates and stayed on 3.10.0-229.14.1. Now that 7.2 is GA, I've made a couple of attempts to update and am running into several problems. First note that I'm in a DoD environment, which means I'm running with selinux=enforcing and auditd/audisp with a heavy ruleset. I have an nVidia Quadro card, and a long time ago switched from the nouveau driver to Nvidia's. So between virtualbox and nvidia, dracut does a lot of work on a kernel update. I've not run into auditd related issues doing minor kernel updates and didn't run into them with the upgrade to the 327 kernel when it first when into 7.1, but it seems that running a yum update to 7.2 caused auditd to induce a kernel panic because the audit message buffer overflowed in the middle of the update. As I recall, that update covered nearly 700 packages, my workstation has around 1700 packages installed. Since then, I have reduced the audit ruleset to the default, and disabled the system that enforces the audit rules, and attempted to complete the half done yum transaction. Both yum-complete-transaction and yum update still responded with the following error: .. --> Processing Conflict: avahi-glib-0.6.31-14.el7.x86_64 conflicts avahi > 0.6.31-14.el7 --> Processing Conflict: libX11-1.6.3-2.el7.x86_64 conflicts libxcb < 1.11-4 --> Finished Dependency Resolution Error: libX11 conflicts with libxcb-1.9-5.el7.x86_64 Error: avahi-glib conflicts with avahi-0.6.31-15.el7.x86_64 You could try using --skip-broken to work around the problem ** Found 91 pre-existing rpmdb problem(s), 'yum check' output follows: PackageKit-glib-1.0.7-5.sl7.x86_64 is a duplicate with PackageKit-glib-0.8.9-11.sl7.x86_64 accountsservice-0.6.35-9.el7.x86_64 is a duplicate with accountsservice-0.6.35-7.el7.x86_64 .. I've successfully removed the avahi package, as I don't need it. Removing libxcb produces a dependency chain of an additional 412 packages to remove - basically all of Gnome/X11, so I didn't attempt that. I've attempted package-cleanup tool to list the dupes and run the cleanup, but this results with the following: --> Finished Dependency Resolution Error: Trying to remove "yum", which is protected ** Found 90 pre-existing rpmdb problem(s), 'yum check' output follows: PackageKit-glib-1.0.7-5.sl7.x86_64 is a duplicate with PackageKit-glib-0.8.9-11.sl7.x86_64 Attempting to cleanup dupes again with --skip-broken does not change the result. Anyone have any advice to cleanup this dupes problem? Many thanks!
