Re: RHEL -> SL conversion
Hi Vinod, On Thu, May 7, 2015, at 02:36 PM, Vinod Gupta wrote: > CMS is one of about twenty Physics groups here in Princeton University. > We have our own Linux distribution based on RHEL with a few Princeton > specific home grown RPMs. The CMS group has been using SL. We are trying > to find a most practical way of providing a "SL" environment on top of > RHEL based Linux without having to change the base distribution for the > other 19 groups in the department. I guess Princeton is not the only > University that has and want to maintain their own Linux distribution. > > Since both PU and SL are based on RHEL, I believe, there is lot more > similarity than differences in the two distributions. Can we simply > setup workstations of CMS group using PU linux and then install a few SL > RPMs to convert them to SL? Will it work for CMS work or there are some > fundamental changes which make SL very different, and probably > incompatible with RHEL? > > Thanks, > > Vinod Gupta > Physics department > Princeton University It sounds like you're wanting to know how different SL is from RHEL. I'd suggest taking a look at the SL Release Notes [0] that correspond to the version(s) that you use to derive your PU distribution. The release notes cover packages that are added to SL that aren't in upstream, packages that are modified, and packages that are removed. On the whole, I'd be very wary of mixing and matching repositories and / or arbitrary packages, but if you decide that you can manage it, the release notes should at least be a good starting point. Feel free to follow-up with the list if you have other questions. Also, thanks to the SL team for making it clear how they diverge from upstream. :) Jim [0] http://ftp.scientificlinux.org/linux/scientific/7.0/x86_64/os/sl-release-notes.html
Re: SL7 Gnome auto-logout doesn't seem to work
Hi Gilbert, On Mon, Jun 8, 2015, at 03:04 PM, Gilbert E. Detillieux wrote: > I had a working setup for our lab computers running SL6, so that Gnome > sessions would auto-logout after some number of hours (since students > would often lock and abandon sessions for days). I'm trying to > replicate this same behaviour under SL7, but (of course) Gnome settings > have changed drastically since SL6. > > I thought I had a solution when I followed the instructions found here: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/user-sessions.html > (Search for "logout" on the page.) > > However, that setup doesn't seem to work, as my idle session stays > locked well past the specified inactive timeout. (And, yes, I > remembered the "dconf update" and remembered to log out and back in. I > even tried rebooting, in case something was being cached.) > > Has anyone come across this one? Any ideas on how to fix it? I'm > coming up empty on my Google searches. > > Thanks, > Gilbert Can you try this? I have tested it, and was able to get it to work for me. We should file a bug against the upstream docs, though. The commands should be entered with root or sudo privileges (shown here as root). The dashes are just shown to separate the commands from the text. You shouldn't include the dashes in your file, though. # vi /etc/dconf/profile/user user-db:user system-db:local # mkdir -p /etc/dconf/db/local.d/locks # vi /etc/dconf/db/local.d/00-autologout [org/gnome/settings-daemon/plugins/power] # Set the timeout to 900 seconds when on primary power sleep-inactive-ac-timeout=900 # Set action after timeout to be logout when on primary power sleep-inactive-ac-type='logout' this next step prevents regular users from changing the setting... # vi /etc/dconf/db/local.d/locks/autologout # Lock automatic logout settings /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-timeout /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type # dconf update You'll need to log out and log back in for the settings to take effect. Let us know if it works for you. Thanks, Jim
Re: SL7 Gnome auto-logout doesn't seem to work
Hi Gilbert, On Tue, Jun 9, 2015, at 10:54 AM, Gilbert E. Detillieux wrote: > On 08/06/2015 10:20 PM, Jim Campbell wrote: > > Can you try this? I have tested it, and was able to get it to work for > > me. We should file a bug against the upstream docs, though. > > > > The commands should be entered with root or sudo privileges (shown here > > as root). The dashes are just shown to separate the commands from the > > text. You shouldn't include the dashes in your file, though. > > > > # vi /etc/dconf/profile/user > > > > user-db:user > > system-db:local > > > > I didn't create this file, as it already was installed as part of the > dconf-0.16.0-6.el7.x86_64 package, and contained the following: > > user-db:user > system-db:local > system-db:site > system-db:distro > > The extra system-db records shouldn't be a problem, since they don't > override the settings we're interested in. > > > # mkdir -p /etc/dconf/db/local.d/locks > > Also existed already, as part of the same dconf package. > > > # vi /etc/dconf/db/local.d/00-autologout > > > > [org/gnome/settings-daemon/plugins/power] > > # Set the timeout to 900 seconds when on primary power > > sleep-inactive-ac-timeout=900 > > # Set action after timeout to be logout when on primary power > > sleep-inactive-ac-type='logout' > > > > I did this, but using a different (larger) timeout value. I've since > played around with the timeout value, and found that it worked for very > small values (e.g. 300). My current hunch (which I'm still testing) is > that it works as long as the screensaver and/or screen lock hasn't > kicked in yet. (I'm trying to find out which of the two might be the > issue.) > > > this next step prevents regular users from changing the setting... > > > > # vi /etc/dconf/db/local.d/locks/autologout > > > > # Lock automatic logout settings > > /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-timeout > > /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type > > > > > > # dconf update > > > > You'll need to log out and log back in for the settings to take effect. > > I had initially skipped the step of creating the lock file, since I > didn't think it would affect the testing. When things didn't work > initially, I created the file (exactly as above), and redid these last 2 > steps, but it made no difference. > > > Let us know if it works for you. Thanks, > > I'll report back after I've found more about what timeout values work > and which don't, and how that compares to my screensaver/screen-lock > settings. > > -- > Gilbert E. Detillieux E-mail: > Dept. of Computer Science Web: > http://www.cs.umanitoba.ca/~gedetil/ > University of Manitoba Phone: (204)474-8161 > Winnipeg MB CANADA R3T 2N2 Fax:(204)474-7609 Interesting. I tested this with a short timeout (2min - 600 seconds) myself, and didn't test it with a longer timeout. I'll try a longer timeout, too. Jim
Re: SL7 Gnome auto-logout doesn't seem to work
Hi, On Tue, Jun 9, 2015, at 11:56 AM, Jim Campbell wrote: > Hi Gilbert, > > On Tue, Jun 9, 2015, at 10:54 AM, Gilbert E. Detillieux wrote: > > On 08/06/2015 10:20 PM, Jim Campbell wrote: > > > Can you try this? I have tested it, and was able to get it to work for > > > me. We should file a bug against the upstream docs, though. > > > > > > The commands should be entered with root or sudo privileges (shown here > > > as root). The dashes are just shown to separate the commands from the > > > text. You shouldn't include the dashes in your file, though. > > > > > > # vi /etc/dconf/profile/user > > > > > > user-db:user > > > system-db:local > > > > > > > I didn't create this file, as it already was installed as part of the > > dconf-0.16.0-6.el7.x86_64 package, and contained the following: > > > > user-db:user > > system-db:local > > system-db:site > > system-db:distro > > > > The extra system-db records shouldn't be a problem, since they don't > > override the settings we're interested in. > > > > > # mkdir -p /etc/dconf/db/local.d/locks > > > > Also existed already, as part of the same dconf package. > > > > > # vi /etc/dconf/db/local.d/00-autologout > > > > > > [org/gnome/settings-daemon/plugins/power] > > > # Set the timeout to 900 seconds when on primary power > > > sleep-inactive-ac-timeout=900 > > > # Set action after timeout to be logout when on primary power > > > sleep-inactive-ac-type='logout' > > > > > > > I did this, but using a different (larger) timeout value. I've since > > played around with the timeout value, and found that it worked for very > > small values (e.g. 300). My current hunch (which I'm still testing) is > > that it works as long as the screensaver and/or screen lock hasn't > > kicked in yet. (I'm trying to find out which of the two might be the > > issue.) > > > > > this next step prevents regular users from changing the setting... > > > > > > # vi /etc/dconf/db/local.d/locks/autologout > > > > > > # Lock automatic logout settings > > > /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-timeout > > > /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type > > > > > > > > > # dconf update > > > > > > You'll need to log out and log back in for the settings to take effect. > > > > I had initially skipped the step of creating the lock file, since I > > didn't think it would affect the testing. When things didn't work > > initially, I created the file (exactly as above), and redid these last 2 > > steps, but it made no difference. > > > > > Let us know if it works for you. Thanks, > > > > I'll report back after I've found more about what timeout values work > > and which don't, and how that compares to my screensaver/screen-lock > > settings. > > > > -- > > Gilbert E. Detillieux E-mail: > > Dept. of Computer Science Web: > > http://www.cs.umanitoba.ca/~gedetil/ > > University of Manitoba Phone: (204)474-8161 > > Winnipeg MB CANADA R3T 2N2 Fax:(204)474-7609 > > Interesting. I tested this with a short timeout (2min - 600 seconds) > myself, and didn't test it with a longer timeout. I'll try a longer > timeout, too. > > Jim I chatted with the upstream maintainers on IRC, and they are going to check this out. I've filed a bug [0], so kindly keep an eye on that, and add any comments / updates to that bug report. As a note, I was able to get things to work with a 15 minute timeout just by following those instructions, but haven't attempted an auto-logout after several hours. Cheers, Jim [0] https://bugzilla.redhat.com/show_bug.cgi?id=1230172 P.S. 2 minutes is 120 seconds. : )
Re: [SCIENTIFIC-LINUX-USERS] GDM login screen (dconf and system name)
At the bottom of each page in the GNOME docs, there's a short blurb that says, "Got a comment? Spotted an error? Found the instructions unclear? Send feedback about this page." Sending feedback sends a message to a mailing list that is monitored by the docs team. I think that the person who monitors that mailing list most regularly is also the person who works on the sysadmin guide, so submitting your feedback there would be as good as a bug report. You can also file a bug report, too. That link is present on all GNOME help docs on the web, by the way. I think that SL7 is using GNOME 3.8 right now, so this is the page that you'd want to check out: https://help.gnome.org/admin/system-admin-guide/3.8/login-banner.html.en Jim On Fri, Aug 28, 2015, at 01:29 PM, Pat Riehecky wrote: > Typically I find the upstream Gnome3 guide a bit more complete: https://help.gnome.org/admin/system-admin-guide/stable/index.html.en > > I do not see a suitable setting there either. > > Pat > > On 08/28/2015 01:23 PM, Nathan Moore wrote: >> In older versions of SL one could include the machine name in the login banner. Somethings like "%n.university.edu" in the login banner config screen would produce "physics1.university.edu" at the login screen. >> >> In the present RHEL7 documentation (link below) I don't see this option in the dconf docs. Is there an easy way to include machine name in the gdm login screen? >> >> reference, >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/customizing-login-screen.html >> >> -- >> - - - - - - - - - - - - - - - - - - - - - >> Nathan Moore >> Mississippi River and 44th Parallel >> - - - - - - - - - - - - - - - - - - - - - >> > > -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory > www.fnal.gov www.scientificlinux.org
Re: a year later - CERN move to Centos - what are we doing?
On Tue, Jan 12, 2016, at 05:43 PM, Konstantin Olchanski wrote: > On Tue, Jan 12, 2016 at 09:48:23AM +, lejeczek wrote: > > > > I personally am just about to trial a migration from SL7 to Centos. > > I'm thinking it's inevitable, am I wrong? > > > > I tried both SL7 and CentOS7 (and I have CC7 machines running at CERN). > > The installer for both have the same idiotic "you *must* create a fake > user or no login prompt for you!", > and the same "you *must* use the disk partition tool designed by dummies > for dummies". > > So no practical difference at installation. Both installers boot from USB > flash, > no need to engrave the ISO images into stone tablets (an improvement over > SL6). > > After installation, I do not have to setup a local mirror for CentOS7 > repositories - CentOS7 automatically > finds and downloads all packages from the very super fast mirror at > SFU.ca. This is > compared to SL7 which very-very-very-very-very-very slowly slowly slowly > downloads all packages from Fermilab. > > So one difference there. Others have covered some of the points here. With regards to the mirrors and download speed, it seems that CentOS installs the yum-fastestmirror package by default, while perhaps Scientific Linux does not. I don't really see this as a big issue for SL, though. If you install the yum-fastestmirror package, you won't default to downloading from the Fermilab repositories. There are a good number of SL mirrors available, too, so I don't want people to think of package download speed as some kind of disadvantage for SL. As I understand it, one of the key values of SL is that it allows you to stay on a point release and obtain only security fixes for your packages (someone else mentioned this, too). This is important when running scientific experiments where you can't allow changes in software to impact your research results. Unless something has changed, neither CentOS nor the North American Upstream Vendor provide this service. This feature from Scientific Linux is a valuable one if you need it. Jim
Re: php 5.6
Hello, On Fri, Apr 8, 2016, at 07:40 AM, Stephan Wiesand wrote: > > On 08 Apr 2016, at 14:22, Ralf Farke wrote: > > > > Hi, > > i need php 5.6 for my Owncloud Server 9, installed is 5.4.16 from > > @sl-security. > > I installed the repos epel and webtatic. > > If i try to install php 5.6w i get the error: > > php56w-common conflicts with php-common-5.4.16-36.el7_1.x86_64. > > When i try to delete php 5.4 i get a lot of Software to delete because of > > dependencies, so this is not a solution. > > > > Any suggestions? > > rh-php56 from external_products/softwarecollections? > > > > > Greetings, > > > > Ralf Farke I would agree with Stephan's suggestion, and suggest using Software Collections, as well. One of the Scientific Linux maintainers, Bonnie King, gave a talk on using Software Collections at our GNU/Linux User Group a few years ago. The slides are here [1], and they include some SL-specific commands to get Software Collections installed & some info on using them. Cheers, Jim [1] https://mediagoblin.chicagolug.org/u/chicagolug/m/rh-software-collections/
