Re: bash bugs - alternative shell
On Thu, 2 Oct 2014, Howard, Chris wrote: I'm wondering if the quickest fix for all of the bash bug stuff coming out now is to replace bash with a different shell. For instance, I see that I have /bin/ksh, why not just link that to /bin/bash and ride out the storm? Is that an alternative? Is there any large subsystem that relies on a bash specific feature? The quickest fix really is to install the available patches. https://access.redhat.com/announcements/1210053 https://access.redhat.com/articles/1200223 -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Questions about SL 7.0
On Wed, 3 Sep 2014, R P Herrold wrote: On Wed, 3 Sep 2014, Nico Kadel-Garcia wrote: It's quite galling: the current semi-manual re-assembly of local branches, based on "git log" entries, is winding up lauded as sufficient and superior because, frankly, it's the only thing that's currently supported. Nico I get it -- you are unhappy about unsigned SRPMS. I am located in the US and so readily subject of the reach the upstream as a target for litigation on perceived EULA / terms of use / etc violations. I won't be exposing such a tool publicly, but then ... If you (seemingly offshore from the upstream) really cannot afford the funds for a subscription, and will do the coding of a mrepo / satellite / whatever proxy to retrieve the signed sources, please ... pass the hat, buy a subscription, and just sit down and write the code. It would seem (but you should satisfy yourself) that your downside risk is that they will turn off such a subscription But is is not productive (for you) to carp over and over without taking steps to address your concern, nor (for others) reading mailing lists to wade through 're-runs' of your concern So the solution is anonymous donations of signed SRPMS in an automated fashion ? Has Open Source come to this ? And to what end ? Nico has a good point, and the only course of action is to make this absurd situation clear to the public. The only other two options are: paying and voiding you Red Hat contract or trusting Centos/infra/tooling. If all this is done only to make RHEL and CentOS more compelling offerings (than Oracle Linux, Scientific Linux, ...), it does leave a bad taste :-/ -- Dag
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Fri, 20 Jun 2014, Jamie Duncan wrote: I'm not worried at all if you have a license or not. I'm not your sales rep. :) The way the comment read didn't sit with me well. It sounded dismissive to a lot of work that Red Hatters do for upstream communities all over that allow RHEL, RHEL derivitaves and all other forms of Linux to happen. Not just the kernel, but the un-sexy bits in the middle that make an OS usable. So if I don't agree, or am critical about something Red Hat did, I am dismissive to Red Hat's contributions ? Sorry, but that is not true at all. In this complex world, I think one is allowed to criticize one action without implying everything else... Self-criticism (and yes, I feel part of Red Hat's community) is essential. And a decision that makes Red Hat weaker, weakens my case as well. I also can't agree with the the thought that Red Hatters won't dissent against company decisions that they don't agree with. I'm not going to dig through the world archives this late on a Friday but I just don't accept that assumption. Of course I'm a fanboy and an employee. But I'm those things because I believe in how we try to do things. We don't always get it right (see RHEV 1.0 and other debacles). But we try to. With al due respect, but your response to one point of criticism is probably why someone at Red Hat (unless maybe high up in the organization) may not speak up. It clearly is a management/legal decision and yes, I do believe if you are on the payroll, that is exactly what you are not supposed to question. Red Hat becoming less Open Source may harm the company's public image. And since the CentOS board is on Red Hat's payroll as well, I think they are in the same boat, unfortunately. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Fri, 20 Jun 2014, Mark Stodola wrote: On 06/20/2014 08:55 AM, Dag Wieers wrote: On Fri, 20 Jun 2014, Lamar Owen wrote: > On 06/20/2014 03:55 AM, Dag Wieers wrote: > > > > It may have become a legal question now that the SRPMs are no longer > > available from ftp.redhat.com. That in itself is an unwelcome change. > > It is an unfortunate change, yes, but I prefer to give Red Hat the > benefit of the doubt as far as motivations go, since they could close > it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's > Fedora, so it doesn't count). And SuSE is completely within its > rights under GPL to do how they are doing; this is not a jab against > SuSE, since SuSE has also done and is doing a lot of great work for > open source. (Of course, since I haven't looked for publicly posted > source for SLES in a while, they may have posted it since I last > looked and I just don't know about it.) I am glad you agree that Red Hat now moving closer to what SuSE is doing is unfortunate and not welcomed by the community(*). (*) Where community in my definition excludes people on Red Hat's payroll ;-) Although this discussion seems interesting, I see the same points being reiterated. I don't see how any of this is going to change anything though. RedHat and CentOS are moving forward whether we like it or not and the SL development team are doing what they can within those constraints. If one needs all that integrity and vetting of the source, go fork over the money for a license. I have a license, don't worry. I am a Red Hat customer. But of course, one license will not do. You need a bunch of entitlements to get access to all channels. And on a yearly basis too. HA, RHSCL, ... For only accessing the SRPMs and rebuilding it adds up quickly. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Fri, 20 Jun 2014, Lamar Owen wrote: On 06/20/2014 03:55 AM, Dag Wieers wrote: It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. It is an unfortunate change, yes, but I prefer to give Red Hat the benefit of the doubt as far as motivations go, since they could close it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's Fedora, so it doesn't count). And SuSE is completely within its rights under GPL to do how they are doing; this is not a jab against SuSE, since SuSE has also done and is doing a lot of great work for open source. (Of course, since I haven't looked for publicly posted source for SLES in a while, they may have posted it since I last looked and I just don't know about it.) I am glad you agree that Red Hat now moving closer to what SuSE is doing is unfortunate and not welcomed by the community(*). (*) Where community in my definition excludes people on Red Hat's payroll ;-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Thu, 19 Jun 2014, Lamar Owen wrote: On 06/19/2014 11:47 AM, Patrick J. LoPresti wrote: I do not care what any lawyer has to say on this topic, because this is not a legal question. Sure it is. It may have become a legal question now that the SRPMs are no longer available from ftp.redhat.com. That in itself is an unwelcome change. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7
On Wed, 18 Jun 2014, Lamar Owen wrote: So, somewhat paradoxically, I would have a greater confidence in source from git than source from a signed source RPM, again due to git's design. Yeah, I know, it's not what we're used to, and there is a bit of information that a package.src.rpm has that the git repo won't have, but it's possible to produce binary compatibility without that bit of info. It may seem to be more work, but time will tell. It depends of course who signs it. If the SRPM is signed by Red Hat, and the git commits are signed by CentOS, you cannot really say that it is the same thing. One may claim that it is the same thing, but only Red Hat can prove it for every commit/SRPM. And that is a problem. Your chain of trust becomes one piece longer, and we don't know what that piece exactly entails. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Any 7 rumors?
On Thu, 15 May 2014, Connie Sieh wrote: On Thu, 15 May 2014, Dag Wieers wrote: On Tue, 8 Apr 2014, ToddAndMargo wrote: > Any rumors as to when EL 7 will be out? There was an announcement today from Red Hat about a virtual event named "Redefining the Enterprise OS" at June 10. The content seems to be centered around RHEL7 features and functionality, so there is a big chance that this is around the time RHEL7 goes GA. The RHEL 7 Public Release Candidate has been out since April 21. Our complete guess is June or early July. So "This redefining the OS" sounds probable. Only guessing . Adding some more guesswork, if they would plan a virtual event around the time RHEL7 is released, my take is that the golden release is ready now (or at least not being delayed for any blocking issues). So any required changes after this date would be released as updates. We can start placing bets and then verify who won at GA time ;-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Any 7 rumors?
On Tue, 8 Apr 2014, ToddAndMargo wrote: Any rumors as to when EL 7 will be out? There was an announcement today from Red Hat about a virtual event named "Redefining the Enterprise OS" at June 10. The content seems to be centered around RHEL7 features and functionality, so there is a big chance that this is around the time RHEL7 goes GA. I can only find this link online from a tweet: http://buff.ly/1uwrDQw Beware that even when RHEL7 goes GA in June, I wouldn't put it into production until RHEL7.1, possibly RHEL7.2 (about a year later) after rigorous testing and integration. (Likely depends on your use-case though) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Security ERRATA Important: openssl on SL6.x i386/x86_64
On Wed, 9 Apr 2014, David Sommerseth wrote: On 09/04/14 16:42, Pat Riehecky wrote: All applications linked against openssl must be restarted for this update to take effect. I installed lsof on my boxes and used [root@host: ~]# lsof | grep -E "libcrypto|libssl" | grep DEL to identify processes/services which needs to be restarted. This is incorrect, only libssl is relevant. Therefore sshd, snmpd, saslauthd or ntpd are not affected since they link only to libcrypto.so. So this suffices: # lsof | grep -P "\bDEL\b.+libssl.so.1.0.1e$" and it will not catch any older processes still using the RHEL6.4 openssl libraries (in case your system was not rebooted after the upgrade to RHEL6.5). -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: LibreOffice Headless
On Tue, 29 Jan 2013, zxq9 wrote: On 01/28/2013 03:17 AM, Gerald Waugh wrote: Hello, Anyone running LibreOffice on a Server? Appreciate ideas on how to implement some of the MS office features on a Web Server TIA No idea what features you are looking to implement, but if the goal is to have your web server generate ODF files natively... I've found it a lot easier to generate ODFs directly from templates rather than go through LibreOffice. I've written tools to do this for me from within Django and Snap but haven't gone to the trouble to generalize (or clean up) the solution. ODF turns out to be wonderfully easy to generate, parse, manipulate, etc. and is now the only XML format that doesn't make me gag. This might not be at all the direction you are trying to head in, but if it is a "generate docs/spreadsheets/charts/etc from source data" type problem don't write off the idea of generating your own from an extension to your web framework. If you're looking into generating ODF output from a structured language (for documentation/publishing purposes) take a look at: http://github.com/dagwieers/asciidoc-odf Unfortunately, Github broke native asciidoc support for the README, so you better read that from: https://github.com/dagwieers/asciidoc-odf/blob/master/README.asciidoc Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: ntop for EL6
On Fri, 14 Sep 2012, Nico Kadel-Garcia wrote: On Thu, Sep 13, 2012 at 7:20 PM, Henrique Junior wrote: Hello, Volker I'm already a Fedora packager (not an experient one) and I'd love to put ntop in EPEL (it is in EPEL for EL5). The problem in maintain ntop in EPEL6 is that Fedora now uses systemd to manage our services instead of sysv. It is a Fedora policy to keep only one spec file and that spec is not compatible with EL6 anymore. That is why I believe that RPMForge is the better option. I'm open to ideas to make this package as useful as possible. RHEL 6 still uses primarily init scripts. Fedora 17 or later, however, uses systemd, and the disparity is going to become more of a problem for EPEL and Repoforge package maintainers. We're going to have to publish two startup files, and install based on which OS is selected. I'm facing similar work with Subversion and the svnserve init script. It's not a problem for Repoforge in the sense that we do allow to have more than one SPEC file if that's needed. We just don't enforce one spec file per distribution as a default because there are more cases that don't need it, than the cases that do need it. But if the complexity of having one SPEC file becomes too heavy, maintaining two is the pragmatic way forward. In the case of systemd in RHEL7, that may well be the case. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: SL on ARM
On Mon, 26 Mar 2012, Gordan Bobic wrote: I recently became aware that the CentOS guys are working on this as of recently, so I thought I'd see if any SL users may also be interested in such a thing. A similar ARM distro already exists, though. Those interested in an ARM port may want to take a look at RedSleeve Linux, which is an ARM port of the same upstream distribution as SL and CentOS. You can look here for more info: http: //www.redsleeve.org/about/ http: //www.redsleeve.org/ In total 109 SRPMs had to be modified in order to get them to build and work on ARM. They are in SRPMS/changed directory on the RedSleeve mirror. (Note: About 5 of those 109 were changed in order to remove the upstream branding which isn't relevant to the SL effort as it is already taken care of. It is quite well known what those are.) Interesting ! Thanks for the link :) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Docbook, Publican, docbook-utils?
On Tue, 6 Mar 2012, Mark Stodola wrote: Does anyone have any recent experience writing documentation in docbook with current tools? I'm in the process of updating a user manual that I wrote several user ago in docbook xml that used xsltproc, fop, and docbook 4.1.x definitions. It looks like I've fallen behind and new tools are around. A search shows that supposedly TUV is using a tool set called Publican, but information is scarce. I also see docbook-utils and docbook-utils-pdf as available packages. Grabbing the latest fop and definitions is giving me quite a screen full of errors. There must be an easier way by now. I'd like to continue to generate html, pdf, and ps output at a minimum. What are people using for a tool chain these days? I prefer AsciiDoc for writing/collaborating on documentation. And am working on an ODF backend for AsciiDoc so you can go directly from AsciiDoc to ODF to PDF/DOC/... while styling through LibreOffice. http://github.com/dagwieers/asciidoc-odf AsciiDoc converts to HTML by default. http://www.methods.co.nz/asciidoc/ But since AsciiDoc translates well to DocBook, you can go from AsciiDoc to DocBook to FOP to PDF, as you're used to. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Wine RPM's
On Mon, 27 Feb 2012, Todd And Margo Chester wrote: On 02/27/2012 02:23 PM, Dag Wieers wrote: The 32bit packages are not in the 64bit repository, that's still an issue. You can manually download the packages, or add the 32bit repository and cherry-pick the wine-packages using includepkgs = wine* Would there be an utility in removing the 64 bit wine packages and only installing the 32 bit ones? I don't think it exists. I am surprised you have a 64bit wine installed. I was under the impression that a pure 64bit wine was unable to run 32bit applications. I will investigate... -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Wine RPM's
On Mon, 27 Feb 2012, Todd And Margo Chester wrote: On 02/27/2012 07:23 AM, Dag Wieers wrote: On Sat, 25 Feb 2012, Todd And Margo Chester wrote: > Anyone know of a source of up to date RPMs for Wine? You can find the latest 1.4 RC5 at: http://pkgs.repoforge.org/wine/ Or by enabling the Repoforge (RPMforge) testing repository. Repoforge is organised through Github, anyone is able to modify one of our SPEC files and perform a pull-request to get one of the packages updated to a new release. Feel free to use this mechanism in the future: http://github.com/repoforge Kind regards, Very cool! Thank you! Problem: # yum --enablerepo=rpmforge-testing upgrade wine ... No Packages marked for Update Bummer! Checking my current install: # rpm -qa \*wine-core\* wine-core-1.2.3-1.el6.x86_64 I am running the x86_64 and all of the packages on http://pkgs.repoforge.org/wine/ are .i386. I do not run *ANY* 64 bit windows programs. Do you recommend I uninstall my x86_64 wine and reinstall your .i386 version? If so, is there some "override" command in "yum" to tell it I want your i386 packages? The 32bit packages are not in the 64bit repository, that's still an issue. You can manually download the packages, or add the 32bit repository and cherry-pick the wine-packages using includepkgs = wine* -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Wine RPM's
On Sat, 25 Feb 2012, Todd And Margo Chester wrote: Anyone know of a source of up to date RPMs for Wine? You can find the latest 1.4 RC5 at: http://pkgs.repoforge.org/wine/ Or by enabling the Repoforge (RPMforge) testing repository. Repoforge is organised through Github, anyone is able to modify one of our SPEC files and perform a pull-request to get one of the packages updated to a new release. Feel free to use this mechanism in the future: http://github.com/repoforge Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: 20 Firefox processes
On Thu, 9 Feb 2012, Andrew Z wrote: i guess i just woke up, but i'm not sure i have seen ~20 firefox ( /usr/lib64/firefox/firefox) proceeses together with 7 /usr/lib64/xulrunner-8/plugin-container /usr/lib64/flash-plugin/libflashpagin ... ) running on my machine. I have 4 core Phenom if it matters. but basic question is - why ? Do you have a cat ? -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: serious bug in boot sequence when fsck is required
On Mon, 30 Jan 2012, Nico Kadel-Garcia wrote: Ok, I now see what you mean. It is rather confusing to refer as the filesystem having problems is /mnt/sysimage, while that is not the location where it normally is mounted. If you would have mentioned it was your root filesystem, that would have been more clear. Dag, this is the default location that the rescue CD or media use, and where the installer mounts the filesystems when doing installations. It's very useful to be able to "chroot" into that environment to run commands on the "local" system, and this is how the installer does things as well for "after rpm is run" operations or '%post" operations from a kickstart setup. I know, that is why I was confused. Why would anyone refer to the /mnt/sysimage filesystem, while in fact it was the root filesystem (and it was even corrupt!). BTW I am surprised you are not using LVM either. I find it very strange to see in this day and age a system still using mere partitions and ext2. This 2012, we left filesystem on partitions at least 2 major release (about 6 years) ago :) For many systems, especially virtualized systems, it's a waste of time and of computational resources. It also makes accessing a virtualized filesystem for system migration or recovery more awkward. Not that this host was virtualized, but there are plenty of reasons to avoid the unnecessary complexity and simply have a /boot, /, and swap space if you need them. I've even had good success with only a / partition in many virtualized systems. Even a virtualized system might need a filesystem that needs to grow over time. Without LVM, and with partitions this can become problematic. Besides, unless you are a computer LVM does not add complexity, it reduces complexity ;-) Even the overhead is minimal. But hey, if people prefer ext2 and partitions, I don't mind. But then don't expect people to care when your root filesystem is corrupt and this leads to various other problems :) Same for LVM, the moment you need it and you want to manually fix a partition that becomes too small, don't expect me to care when you accidentally destroy your filesystem because of incorrect partition boundaries or incorrect copy instructions or whatnot. If you know what you're doing, I don't mind, but let's stick to the case at hand :) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: serious bug in boot sequence when fsck is required
On Mon, 30 Jan 2012, Yasha Karant wrote: On 01/30/2012 03:35 PM, Dag Wieers wrote: I wonder: - whether you were in fact using a journalling filesystem (because it should even recover from power failure like that when it is journalled) For the most part, for a number of reasons, we are sticking with ext2, with -- in the case of my workstation -- fuse ntfs for MS Windows which is required for particular unpleasantries. We have not made a production change to ext4, but are considering the transition. We are attempting to get detailed data on the reliability of the ext4 filesystem, how much overhead (loss of data capacity) ext4 requires, and the performance change (loss?) between ext2 and ext4. Any detailed, preferably quantitative, comparisons on production systems will be appreciated. I wonder why you chose ext2 over ext3. The cause of all your troubles is because you did not opt for the journaling filesystem. And ext3 is nowadays a lot more tested and a safer option than ext2. Ext4 does not have the same maturity/reliability as ext3, but it is getting there. You can find benchmarks on the net wrt. ext2 vs ext3 vs ext4. Comparisons based on production systems depends completely on workload and I/O patterns and do not necessarily translate back to your systems (at least not if the I/O patterns are not known). - what was mounted on /mnt/sysimage (as normally this is your root-filesystem during installation, not during runtime) I did a manual umount from the rescue running image, and verified with mount that /mnt/sysimage was not mounted . Nonetheless, when the production system attempted to reboot, it reported that the /dev/sda5 was not cleanly unmounted, and started automatic fsck. This fsck failed, with the request that I manually run fsck -- an operation I could not do as the root password was not accepted, being truncated by the root password input procedure. Ok, I now see what you mean. It is rather confusing to refer as the filesystem having problems is /mnt/sysimage, while that is not the location where it normally is mounted. If you would have mentioned it was your root filesystem, that would have been more clear. BTW I am surprised you are not using LVM either. I find it very strange to see in this day and age a system still using mere partitions and ext2. This 2012, we left filesystem on partitions at least 2 major release (about 6 years) ago :) Do the above comments clear the fog? A bit. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: serious bug in boot sequence when fsck is required
On Mon, 30 Jan 2012, Yasha Karant wrote: We had a massive power failure, beyond what the UPS could handle. Despite attempts to find a way for the system to shut down gracefully, it simply powered down without unmounting the disk partitions. Nominally, the backup local UPS I am using (APC Back-UPS 650) has an interface Port DB-9 RS-232 but I have not found any Linux application that reliably would communicate with this model of UPS (that is, emulate the same behavior as the application available from APC for MS Win that senses the RS-232 information from APC, waits the appropriate time, and then shutdown -- anyone found one?). Upon boot, automatic fsck failed, and a request was posted for root password. However, no more than one character of the password would be accepted, causing an endless loop to this condition and not allowing me control of the system (run fsck manually). Hi Yasha, I wonder: - whether you were in fact using a journalling filesystem (because it should even recover from power failure like that when it is journalled) - what was mounted on /mnt/sysimage (as normally this is your root-filesystem during installation, not during runtime) - why you couldn't disable the filesystem in /etc/fstab, reboot and fix it after the system would have booted normally - why a filesystem like /mnt/sysimage is configured to stop the boot-process when it has issues (man fstab, check sixth field) Thanks in advance for clearing the fog, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: why wine 64 pulls tons of 686 deps
On Sun, 29 Jan 2012, Andrew Z wrote: i was thinking of installing Teamviwer, but it seemed to require either tons of 86 libs to satisfy it's rpm's dependecies or wine. -snip- I'm curious why would it need 686 deps? Because even the 64bit Windows provides 32bit compatibility, people expect the same from Wine. A pure 64bit Wine would be rather useless to most people. Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: kernel-ml is not for production use
On Tue, 1 Nov 2011, Yasha Karant wrote: How does the above lack of warranty from a commercial for-profit vendor differ from the "These packages are provided As-Is with no implied warranty or support" from el-repo or the similar disclaimer from SL? This is not a discussion of specific ElRepo packages, but a general question of interest to all users of packages advertised on the SL list -- ElRepo in this particular instance. Yasha, I am certain that even you must understand the difference between paid-for support by the largest Linux vendor on the planet for a kernel run by tens of millions, and a handful of people providing an alternative kernel (that could be useful to some users). Even with the legalese. I don't know what you are getting at though. If you think running kernel-ml in production, feel free to do so on your own terms, the ELRepo project however does not advise to use kernel-ml for production use and doesn't want people to assume that it provides the same maturity, reliability, security or support as the upstream kernel releases. http://elrepo.org/tiki/kernel-ml Can we now please end this thread ? If you like to continue your own thoughts on certain matters, feel free to do so on your own blog. I however don't see the merits of picking on people's words. Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Fri, 7 Oct 2011, Vladimir Mosgalin wrote: On 2011.10.07 at 01:34:38 +0200, Dag Wieers wrote next: Evidently, a number of stock end-user applications, such as Firefox, Thunderbird, and the like, have security holes as well as bugs, and thus need regularly kept current. Do you have any proof of security problems ? Was there a security advisory for this release ? It's not as simple as that. There was no supported version of 64-bit flash 10 plugin. Information about security problems in betas and RCs of flash plugins aren't displayed on that page that you saw - it does, however, appear in news from adobe and in adobe blogs; but they don't add them to list of problems in final releases. I am nog arguing about that. But people using 64bit flash plugins did not have any security for months either. I personally don't care about security for people that don't care about security :) But that said, now that an official 64bit release is out, we have it too. Btw, 64-bit flash 10 plugin was even in more sorry state: there were lot of known security problems for it, but adobe stopped developing it and latest known (beta) version was said to be very vulnerable. Again, no arguing against that. If you look at the mail(s) I was replying too, I was answering to the general view that: - Not having the latest flash-plugin is a security problem - Red Hat is failing to provide a secure flash-plugin Both statements are false, unless you apply them (only) to already insecure situations (eg. 64bit beta). Which is more of a mental excercise anyway. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Fri, 7 Oct 2011, Robert E. Blair wrote: Dag Wieers wrote: | Again, without any information it is hard to determine whether the | plugincheck is mainly checking the version against the latest (known) | available, or whether it actually knows about vulnerabilities. | | I bet the first option is what is implemented (because the second adds | complexity without any real gain). Their aim is to have people running | the latest. | | ALso, if we look at TUV, they still offer | flash-plugin-10.3.183.10-1.el6, which is most likely not vulnerable (and | which was the version offered by Repoforge until this morning too). In | other words, we are now disconnected from the RHSA information. The 64 bit version I installed an hour or so ago from the Adobe yum repo is: flash-plugin-11.0.1.152-release.x86_64 Ok, let's hope I can kill this thread with actual vendor information instead. On the Adobe website, there's even no mention of flash-plugin v11. http://www.adobe.com/support/security/#flashplayer So as I suspected, the new v11 release is just the first official release announcement, which is *NOT* security-related. At least there is not information to support such claims, and no proof that the v10 offering is vulnerable. Wrt. to Red Hat not tracking flash-plugin security updates. As far as I can tell, TUV has the latest flash-plugin v10, so there is no security impact. TUV provides flash-plugin-10.3.183.10-1.el6, which is newer than the latest Adobe security bulletin from the Adobe page above. Executive summary: - Do not mix 32bit and 64bit flash-plugin packages. Decide which to use and stick to it. - New Adobe releases do not imply new security vulnerabilities. - Red Hat is offering a secure flash-plugin offering (even newer than the latest Adobe security bulletin), even when it is not the latest and greatest (just-released) v11. Please only reply to this thread if you have new information and some references to back it up. Thanks :-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Fri, 7 Oct 2011, jdow wrote: In that vein it seems "odd" to me that a 32 bit package would be accepted as an update for a 64 bit package. This seems to be to be a bug. The reason is that some 64bit users have been using 32bit flash-plugins on 64bit. Repoforge for some time (and now Adobe) offer 64bit flash-plugin packages, but a lot of 64bit users have the 32bit repository enabled. Hence you get those conflicts. There is nothing I can do regarding this. Users having problems may have to change their configuration and use the 64bit plugin instead. The only thing that is under my control is keeping the flash-plugin up-to-date. Which is not that simple, because Red Hat is at flash-plugin v10 and Adobe does not release any security information, nor is there something I can subscribe to to get informed of updates. Although I did add the 32bit and 64bit repositories to my local mrepo instance. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Thu, 6 Oct 2011, Yasha Karant wrote: On 10/06/2011 04:37 PM, Dag Wieers wrote: On Thu, 6 Oct 2011, Yasha Karant wrote: > I realise that except for the Fermilab/CERN staff persons, almost all > of the rest of those maintaining material for SL are unpaid > volunteers. With that stated, what is the > typical/average/median/whatever delay from the Adobe release until the > SL compatible port for the flash plugin? > > In some cases, Adobe adds functionality -- but in most cases it is a > matter of bug and security-hole fixes -- and the sooner one installs a > valid security fix, the better. Do you have proof that this is a security fix. Because I track the RHEL packages and no such update has come through their channels. It seems as if the release was simply their official Flash Player 11 release, rather than a security fix. If it is a security fix, even Red Hat is behind. Somehow I don't believe that, but for you to provide proof of what you state. Thanks. I use the direct Mozilla (and OpenOffice) distributions and updates. For Firefox 7.x (that the Firefox update on Help --> About Firefox reports as up to date), I ran an update check on the addons, including plugins using Tools --> Add ons and URL https://www.mozilla.org/en-US/plugincheck/ and the following was displayed: Vulnerable plugins: Plugin Icon Shockwave Flash Shockwave Flash 11.0 r1 Vulnerable (more info) (11.0.1.129 is what actually is installed) Again, without any information it is hard to determine whether the plugincheck is mainly checking the version against the latest (known) available, or whether it actually knows about vulnerabilities. I bet the first option is what is implemented (because the second adds complexity without any real gain). Their aim is to have people running the latest. ALso, if we look at TUV, they still offer flash-plugin-10.3.183.10-1.el6, which is most likely not vulnerable (and which was the version offered by Repoforge until this morning too). In other words, we are now disconnected from the RHSA information. If you noticed a flash-plugin update from Adobe, feel free to let us know so we can update our flash-plugin package too. Thanks in advance, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Fri, 7 Oct 2011, JR van Rensburg wrote: On Fri, 2011-10-07 at 01:19 +0200, Dag Wieers wrote: It's quite hard to release before Adobe. The way I understand it from pre 64-bit Flash, Adobe weren't responsible for the 64-bit Flash development and it came with the caveat that it won't be updated from their repo. This meant that you only got the 32-bit plugin from adobe. The issue is mixing 32bit and 64bit packages. The exact same error would have happened if you had the old 32bit flash-plugin installed, and would install the 64bit new plugin. I don't see exactly what everything else has to do with anything. Tomorrow the 11.0.1.152 will be available from Repoforge, for both 32bit and 64bit. And any issues are resolved, but we can never proactively prevent something we cannot control. If tomorrow Adobe releases a newer 32bit RPM and people use that repository on 64bit using the Repoforge 64bit package, we could not have prevented that... Without Adobe Flash the world would be much more simple, Steve Jobs knew that :) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Thu, 6 Oct 2011, Yasha Karant wrote: On 10/06/2011 04:19 PM, Dag Wieers wrote: On Thu, 6 Oct 2011, Dr Andrew C Aitchison wrote: > On Thu, 6 Oct 2011, Dag Wieers wrote: > > On Thu, 6 Oct 2011, Dr Andrew C Aitchison wrote: > > > On Thu, 6 Oct 2011, Dag Wieers wrote: > > > > > RPMforge provides already the (beta) 64bit flash-plugin, so > > there's > > no > > > > need to wait for it. In this case the 64bit is installed, so > > there is > > no > > > > reason to install the 32bit. Unless you want to replace the 64bit > > by > > the > > > > 32bit. > > > > Hmm. Unless I am using an out of date mirror RPMforge has > > > flash-plugin.x86_64 11.0.1.129-0.1.el6.rf rpmforge > > > > whereas the adobe-linux-i386 repo has > > > flash-plugin.i386 11.0.1.152-release @adobe-linux-i386 > > > (Build Date: Sat 24 Sep 2011 02:45:27 AM BST). > > > > So, why would one replace a 64bit flash-plugin with a 32bit one ? > > Not so much that I want to - rather that the 32 bit adobe repo was > already enabled from when the machine was running SL5 and I have > only now looked for the adobe-linux-x86_64 repo. > > My real point was that the rpmforge plugin is presumably out of > date if the adobe repo has a newer plugin with a higher release number. It's quite hard to release before Adobe. I realise that except for the Fermilab/CERN staff persons, almost all of the rest of those maintaining material for SL are unpaid volunteers. With that stated, what is the typical/average/median/whatever delay from the Adobe release until the SL compatible port for the flash plugin? In some cases, Adobe adds functionality -- but in most cases it is a matter of bug and security-hole fixes -- and the sooner one installs a valid security fix, the better. Do you have proof that this is a security fix. Because I track the RHEL packages and no such update has come through their channels. It seems as if the release was simply their official Flash Player 11 release, rather than a security fix. If it is a security fix, even Red Hat is behind. Somehow I don't believe that, but for you to provide proof of what you state. Thanks. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Thu, 6 Oct 2011, Yasha Karant wrote:
On 10/06/2011 10:08 AM, Dag Wieers wrote:
On Thu, 6 Oct 2011, Dr Andrew C Aitchison wrote:
> On Thu, 6 Oct 2011, Dag Wieers wrote:
>
> > RPMforge provides already the (beta) 64bit flash-plugin, so there's no
> > need to wait for it. In this case the 64bit is installed, so there is
> > no
> > reason to install the 32bit. Unless you want to replace the 64bit by
> > the
> > 32bit.
>
> Hmm. Unless I am using an out of date mirror RPMforge has
> flash-plugin.x86_64 11.0.1.129-0.1.el6.rf rpmforge
>
> whereas the adobe-linux-i386 repo has
> flash-plugin.i386 11.0.1.152-release @adobe-linux-i386
> (Build Date: Sat 24 Sep 2011 02:45:27 AM BST).
So, why would one replace a 64bit flash-plugin with a 32bit one ?
If the 64bit version was used, it simply would have worked.
Unless I misunderstood, the 32 bit version is the current ("most secure")
release, 152, whereas the 64 bit version is not current, 129.
You indeed misunderstood:
1. There is _now_ also a 64bit 152 release
2. There was no security update release by Red Hat for the flash-plugin.
That is the only source that I can track properly, I do not visit the
Adobe flash-plugin website daily.
3. Feel free to report new flash-plugin release through the github.com
web-interface at: http://github.com/repoforge
Evidently, a number of stock end-user applications, such as Firefox,
Thunderbird, and the like, have security holes as well as bugs, and thus need
regularly kept current.
Do you have any proof of security problems ? Was there a security advisory
for this release ?
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Thu, 6 Oct 2011, Dr Andrew C Aitchison wrote: On Thu, 6 Oct 2011, Dag Wieers wrote: On Thu, 6 Oct 2011, Dr Andrew C Aitchison wrote: > On Thu, 6 Oct 2011, Dag Wieers wrote: > > > RPMforge provides already the (beta) 64bit flash-plugin, so there's > > no > > need to wait for it. In this case the 64bit is installed, so there is > > no > > reason to install the 32bit. Unless you want to replace the 64bit by > > the > > 32bit. > > Hmm. Unless I am using an out of date mirror RPMforge has > flash-plugin.x86_64 11.0.1.129-0.1.el6.rfrpmforge > > whereas the adobe-linux-i386 repo has > flash-plugin.i38611.0.1.152-release @adobe-linux-i386 > (Build Date: Sat 24 Sep 2011 02:45:27 AM BST). So, why would one replace a 64bit flash-plugin with a 32bit one ? Not so much that I want to - rather that the 32 bit adobe repo was already enabled from when the machine was running SL5 and I have only now looked for the adobe-linux-x86_64 repo. My real point was that the rpmforge plugin is presumably out of date if the adobe repo has a newer plugin with a higher release number. It's quite hard to release before Adobe. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Thu, 6 Oct 2011, Dr Andrew C Aitchison wrote: On Thu, 6 Oct 2011, Dag Wieers wrote: RPMforge provides already the (beta) 64bit flash-plugin, so there's no need to wait for it. In this case the 64bit is installed, so there is no reason to install the 32bit. Unless you want to replace the 64bit by the 32bit. Hmm. Unless I am using an out of date mirror RPMforge has flash-plugin.x86_64 11.0.1.129-0.1.el6.rf rpmforge whereas the adobe-linux-i386 repo has flash-plugin.i38611.0.1.152-release @adobe-linux-i386 (Build Date: Sat 24 Sep 2011 02:45:27 AM BST). So, why would one replace a 64bit flash-plugin with a 32bit one ? If the 64bit version was used, it simply would have worked. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash plugin
On Thu, 6 Oct 2011, Vladimir Mosgalin wrote: On 2011.10.06 at 05:05:05 -0700, jdow wrote next: Date: Thu, 06 Oct 2011 05:05:05 -0700 From: jdow To: scientific-linux-us...@fnal.gov X-Original-To: mosgalin@localhost Subject: Flash plugin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 I have the elrepo 64 bit beta flash plugin installed. A 32 bit flash update is being forced on my system. Here are the error messages. Transaction Check Error: file /usr/share/applications/flash-player-properties.desktop from install of flash-plugin-11.0.1.152-release.i386 conflicts with file from package flash-plugin-11.0.1.129-0.1.el6.rf.x86_64 There is no flash plugin in elrepo. You seem to have one from rpmforge installed. Either wait until x86_64 package appears in rpmforge, or uninstall it, then install official adobe yum repository and install flash plugin from there.. RPMforge provides already the (beta) 64bit flash-plugin, so there's no need to wait for it. In this case the 64bit is installed, so there is no reason to install the 32bit. Unless you want to replace the 64bit by the 32bit. If that is the case (beware, you may need to change browsers, or install another plugin) you should uninstall the 64bit package first. RPMforge tracks the flash-plugin releases and packages them asap because there is an important security impact for systems that have it installed. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Thank you Connie (Was: Developer history for Scientific Linux)
On Fri, 26 Aug 2011, Connie Sieh wrote: With Troy leaving some may wonder who will "develop" Scientific Linux. I will continue with the Scientific Linux project. I guess it's only appropriate to also thank you for the ongoing effort and for staying with the project ! It would be unfair to only thank when leaving, as I wouldn't want to encourage anyone else leaving ;-) Thanks Connie and the people-behind-the-scene ! -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Farewell from Troy
On Wed, 24 Aug 2011, Troy Dawson wrote: I have loved all the years that I have been a developer and architect for Scientific Linux, but it is time for me to move on. I have accepted a job offer from Red Hat to work on their new openshift project. ( https://www.redhat.com/openshift/ ) My last day working for Fermilab, and on the Scientific Linux project will be September 2, 2011. Hi Troy, Good luck with the new carreer opportunity and thanks for having done what you did so well with Scientific Linux. It is sad to see you leave, but knowing you are going to enforce Red Hat makes up for that largely :-) Do well and keep in touch ! -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: lots of BUG: scheduling while atomic messages
On Mon, 8 Aug 2011, Torsten Luettgert wrote: I recently upgraded one of our KVM servers from SL 6.0 to 6.1. Now (yesterday) the machine was under heavy I/O load. I investigated and saw that all virtual machines with CentOS 5.6 (we switched to SL just a few months ago) are writing hundreds of thousands of these messages to /var/log/messages: Aug 8 13:15:20 infra kernel: : BUG: scheduling while atomic: swapper/0x/0 Aug 8 13:15:20 infra kernel: : Aug 8 13:15:20 infra kernel: : Call Trace: Aug 8 13:15:20 infra kernel: : [] __sched_text_start+0x7d/0xbce Aug 8 13:15:20 infra kernel: : [] default_idle+0x0/0x50 Aug 8 13:15:20 infra kernel: : [] cpu_idle+0xb6/0xb8 Aug 8 13:15:20 infra kernel: : [] start_kernel+0x220/0x225 Aug 8 13:15:20 infra kernel: : [] _sinittext+0x22f/0x236 Aug 8 13:15:20 infra kernel: : Now I'm not sure if this is a problem of the underlying CentOS kernel (that one was upgraded on july, 20th) or of SL 6.1 KVM (upgraded august, 1st). The SL 6.0/6.1 machines don't show this problem. The 5.6 machines didn't under SL 6.0. Right now I disabled the swap which seems to help, but this can of course only be a temporary solution. I also saw that RH released two minor releases of qemu-kvm that aren't yet in SL; would it make sense to try to compile the newest of them and update? If anyone knows something about this problem, any help is greatly appreciated. This seems to be related: https://bugzilla.redhat.com/show_bug.cgi?id=725332 -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: password for singleuser - benefits?
On Sat, 30 Jul 2011, 夜神 岩男 wrote: Coming originally from secret squirrel land, one of the cardinal security rules for us was simply "If the attacker has physical access, you don't have security". I don't agree with you completely, there's many sides to security. Data-theft, denial-of-service, hardware-theft, fire/water damage... Different kinds of measures can help you to protect against one or more of these, but simply stating that a GRUB password, a BIOS password or an encrypted filesystem do not help against someone with physical access is not true. It's the difference between a good lock, a bad lock and no lock. Depending on the determination, the environment and the tools available, a good lock may very well prevent your bike from being stolen. No lock may guarantee it gets stolen (at least in some areas over here). And that's just hardware, you might be concerned with the data-theft. Filesystem encryption doesn't prevent your data to be stolen, but makes it impossible to be abused when stolen. So, yes, even considering physical access, a GRUB and BIOS password is very much recommended. And disabling ctrl-alt-del is a good measure to protect against accidental reboots... Everything adds up to the total security. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Flash-plugin 11 rpmforge freeze full screen using metacity window manager
On Thu, 21 Jul 2011, jonathan wrote: Upon upgrading from flash-plugin-10.3.162.29-0.1.el6.rf (x86_64) to flash-plugin-11.0.1.60.0.1.el6.rf (x86_64), when i switch to full screen mode when playing a video on for example youtube Xorg freezes. When using flash plugin 10 the use of "OverrideGPUValidation=true" in the /etc/adobe/mms.cfg file fixed the problem. Though it does not fix the problem on flash-plugin 11. If the compiz window manager is used fullscreen playback works. Any suggestions? Sorry Jon, Let me clarify that this Flash update was very much needed, even though we go to another Beta. The problem is that the 64bit plugin (square alpha) had lots of security issues. Undoubtedly this release will have some too, but at least anything known is fixed in a more recent release. Here's hoping Adobe will take care of 64bit platforms soon with proper security updates... -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: How to turn off screen saver and DPMS
On Thu, 14 Jul 2011, Michael Jones wrote: Despite this radically overkill approach, the screen still turns off after around half an hour. I suspect that the reason is the monitors built in power saving features, which I believe should be prevented by the "xset -dpms" command, but doesn't appear to be. Does anyone have any ideas? Is there something that can be added to the xorg configuration to prevent the screen from turning off, perhaps? We have been investigating this somewhere in 2008 for a conference (FrOSCon) with the aim of providing 2 large conference screens directing people to various talks at the entrance (a bit like as you can see at airports), but also for the various presentation computers in the various rooms. Obviously, the first year having to provide input every hour to make sure they didn't blank was not very much appeciated. (But hey, CentOS+ELRepo actually worked on the hardware, in contract to latest Fedora and Ubuntu) So our LiveUSB solution that was not designed for it, was not tested for this kind of use. The next year I came up with the following configuration (tested on CentOS 5), which worked: ### Disable screensaver start gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome_settings_daemon/screensaver/start_screensaver false ### Disable screensaver locking gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-screensaver/lock_enabled false ### Disable screensaver altogether gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-screensaver/idle_activation_enabled false ### Increase screensaver idle time (max 2h, we set to 10h) gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-screensaver/idle_delay 600 ### Disable DPMS screen blank on AC and battery gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t string /apps/gnome-power-manager/ac_dpms_sleep_method off gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t string /apps/gnome-power-manager/battery_dpms_sleep_method off ### Disable Computer sleep when on AC and battery gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t integer /apps/gnome-power-manager/ac_sleep_computer 0 gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t integer /apps/gnome-power-manager/battery_sleep_computer 0 ### Disable Display sleep when on AC and battery gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t integer /apps/gnome-power-manager/ac_sleep_display 0 gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t integer /apps/gnome-power-manager/battery_sleep_display 0 ### Disable Dim-on-Idle gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-power-manager/dim_on_idle false ### Other noblank features cat </etc/X11/xinit/xinitrc.d/noblank.sh echo "Disable screen blanking for $TERM and $DISPLAY" setterm -powersave off -blank 0 #xset -dpms xset dpms 0 0 0 xset s noblank xset s off EOF chmod 0755 /etc/X11/xinit/xinitrc.d/noblank.sh It is quite possible some things are redundant, but once it worked I wasn't very interested to find those items that were not helping the cause ;-) Hope this works for you. Do let me know if you can improve this scheme ! Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Enough with the frivolous emails
On Fri, 1 Jul 2011, Troy Dawson wrote: I know that talking about some of these things makes it feel more like a community, but that is not what this mailling list is for. This mailling list is for people to bring questions about Scientific Linux, and hopefully they will get answers. Thanks for making this very clear. Beware that you may have to repeat this from time to time in the future as well ;-) For the record, there is no official SL policy about top posting, bottom posting, middle posting, or threads. To prevent such threads in the future, could we instead provide an official policy, eg. - bottom posting is recommended - commenting about posting-methods to the list is forbidden - personal preferences to posting is discussed in private (Personally I find the remarks regarding top/bottom postings more annoying than the postings themselves, because I've been exposed to this so many times and you cannot change the world, even when one appears better than the other...) Thanks for intervening for the benefit of all ;-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Skype How-To Posted for SL6 x64
On Fri, 24 Jun 2011, John H. Outlan CPA wrote: I posted a how-to here. I saw some questions regarding Skype in earlier mails; therefore I thought it might help some on the mail list. Most of the information I found in various places were incomplete: http://scientificlinuxforum.org/index.php?showtopic=569 I have seen many stability issues using Skype on RHEL 6.1/x86_64. Which was not the case one RHEL6.0/x86_64. Unfortunately, Skype's latest Linux release is 2.2.0.25-fc10 and only for 32bit. (Note that between fc10 and RHEL6 there is a gap of two years...) Hopefully Google Talk becomes a viable option for mainstream use soon. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: clock drift under Hyper-V
On Wed, 1 Jun 2011, Jan van Eldik wrote: > > > I'm running a couple of CentOS 5.6 instances under Hyper-V. Horrible > > > clock drift > > > issues, but otherwise okay. > > > > You may want to add: > > > > divider=10 clocksource=acpi_pm > > Doesn't help me. Just to add that we different parameters on 32bit and 64bit SLC5 systems. From https://cern.service-now.com/kb_view.do?sysparm_article=KB278 * SLC5/x86_64: "divider=10 clock=pmtmr" * SLC5/i386: "divider=10 clocksource=acpi_pm" * SLC4/x86_64: "divider=10 notsc" * SLC4/i386: "divider=10 notsc" These parameters seem to work fine on 500+ VMs Interesting, that's what we did: - EL5/x86_64: elevator=noop divider=10 notsc - EL5/i386: elevator=noop divider=10 clocksource=acpi_pm - EL4/x86_64: elevator=noop divider=10 notsc - EL4/i386: elevator=noop divider=10 clock=pmtmr So it's different for EL5/x86_64 and EL4/i386. This was based on: http://kb.vmware.com/kb/1006427 -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
RE: clock drift under Hyper-V
On Tue, 31 May 2011, Werf, C.G. van der (Carel) wrote: In my opinion you should NEVER use NTPD in a virtual machine. Check out how NTPD works... it tries to adjust "software cycles"to "hardware cycles". "Hardware cycles" are a bit undefined in a virtual machine. It keeps the (virtual) system clock in sync with an external source. This works better than using a timer interrupt, especially when the hypervisor cannot commit to a certain interrupts per second. (Which used to be a problem eg when HZ set to 1000 in VMs) Using ntpd is definitely a best practice we have been using even before VMware recommended it. We had more troubles with VMware's host-guest synchronization. You just have the configure ntpd correctly. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: SL vs. RPMForge repo
On Wed, 18 May 2011, Akemi Yagi wrote: On Wed, May 18, 2011 at 8:53 AM, Orion Poplawski wrote: RPMforge now offers two repos - [rpmforge] and [rpmforge-extras]. Packages in [rpmforge] will not have conflict with the distro ones whereas those in [rpmforge-extras] may overwrite distro files. AH yes, forgot about that. I guess the packages it is wanting to replace on my machine mostly come from EPEL, not the SL repositories. But there is one: # yum list environment-modules Loaded plugins: downloadonly Installed Packages environment-modules.x86_64 3.2.7b-6.el6 @anaconda-ScientificLinux-201102250955.x86_64 Available Packages environment-modules.x86_64 3.2.8a-1.el6.rf rpmforge That one must have been missed. I will let Dag know. Thanks for reporting. Yes, thanks for reporting ! I fixed it yesterday by moving this package to RPMforge-extras. When we started building RHEL6 packages last year, we did a large effort to find those duplicate packages, also for older distributions. The environment-modules RPM is a newly introduced package (I presume for RHEL5 only) and we obviously did not verify if it was already in RHEL6. There's more than one issue here: - if a package is introduced for RHEL5, we need to check if it is needed for RHEL6 and if there's a need to have a different version there. - we should avoid releasing a newer package in RHEL5 than is available in upstream RHEL6. It's often better to backport the RHEL6 package to RHEL5. - we need a (preferably) automated check to avoid this in the future. It would be nice if the packager could easily check before doing any effort at all, but as a last resort the buildsystem should refuse by default. (It's easier to automate on the buildsystem side as a DAR plugin, even when it's still bash :-/) So I am sorry for this mishap, I hope we can avoid it in the future. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: SL vs. RPMForge repo
On Thu, 14 Apr 2011, Alan Bartlett wrote: On 14 April 2011 05:49, Nicolas Kovacs wrote: Quite some familiar names around this mailing list. Smiles. I just discovered that the text-based version of Anaconda has been seriously amputated in functionality. But that's probably an upstream decision. Correct. Plus, I wonder why I can't install SL6 on my good old Fujitsu Lifebook with a Pentium M processor, which the installer kernel refuses to work with. I believe that processor does not support PAE, so you are out of luck. Again, this is a Red Hat decision. The EL6 32-bit kernel is what was a PAE kernel for EL5. Putting it another way, the EL5 32-bit non-PAE kernel has been dropped for EL6 and so what would known as a PAE kernel has had that descriptor removed. There might be a case for a drop-in replacement kernel that supports non-PAE 32bit systems. So at least a PXE/USB installation works fine, without the need to respin the ISO (which may be too troublesome). Of course, that would also mean we'd have to update that non-PAE kernel as part of that repository. If people have a clear need for this (and there is at least one committed to support this) do speak up. It might be the beginning of something beautiful... -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: SL vs. RPMForge repo
On Wed, 13 Apr 2011, Nicolas Kovacs wrote: Le 13/04/2011 20:59, Dag Wieers a écrit : I would be interested to know what yum errors you got, and distribution/arch and other relevant information. :-) Here goes : # cat /etc/issue Scientific Linux release 6.0 (Carbon) # yum repolist repo id repo name status rpmforgeRHEL 6.0 - RPMforge.net - 3 793 sl Scientific Linux 6.0 -2 969 sl-security Scientific Linux 6.0 - updates 552 # yum install mplayer ... --> Finished Dependency Resolution Error: Package: mplayer-1.0-0.46.svn20100703.el6.rf.i686 (rpmforge) Requires: libesd.so.0 Error: Package: dirac-1.0.2-1.el6.rf.i686 (rpmforge) Requires: libcppunit-1.12.so.1 Error: Package: libcaca-0.99-0.1.beta17.el6.rf.i686 (rpmforge) Requires: libglut.so.3 Error: Package: mpg123-1.13.2-1.el6.rf.i686 (rpmforge) Requires: libesd.so.0 Error: Package: mplayer-1.0-0.46.svn20100703.el6.rf.i686 (rpmforge) Requires: liblzo2.so.2 You could try using --skip-broken to work around the problem Any suggestion ? These requirements are all SL 6.0 packages, so I assume there's something wrong with your yum configuration. [dag@moria ~]# rpm -qf /usr/lib64/libesd.so.0 esound-libs-0.2.41-3.1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/libcppunit-1.12.so.1 cppunit-1.12.1-3.1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/libglut.so.3 freeglut-2.6.0-1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/liblzo2.so.2 lzo-2.03-3.1.el6.x86_64 I would start by cleaning the cache: yum clean all -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: SL vs. RPMForge repo
On Wed, 13 Apr 2011, Nicolas Kovacs wrote: I've been a CentOS user for a few years, and I just decided to switch to SL. I installed it on two of my sandbox PCs in my office. First reaction : I like it a lot! I expect a few things to be different than CentOS, and maybe the odd rough edge here and there. First things first. Does the RPMForge third party repo work OK with SL ? Because I just configured it and tried a 'yum install mplayer' and got a load of Yum error messages about missing dependencies. I'm aware this question could possible (also?) belong on the RPMForge mailing list, though I'm not exactly sure. I would be interested to know what yum errors you got, and distribution/arch and other relevant information. :-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: USB 3.0 Support in SL6 Kernel; related issues
On Wed, 23 Mar 2011, john h outlan wrote: Hello fellow users.I recently was having problems mounting usb flash and HD's in SL 6 x64. I tried various things and nothing worked, *until* I went into the BIOS of my Dell Precision Laptop and UNchecked USB 3.0. Upon reboot to the desktop, my external drives now mount and pop right up like they should. However, before my drives stopped working, they were working with USB 3.0 enabled in the BIOS after an NTFS-Config install...but suddenly stopped, or at least I noticed them not working after 2 days or so; that is until I made the BIOS change. So I'm back in business. But the questions linger on. I'm posting this to alert anybody that may be fighting the same thing, as well as to learn about USB 3.0 support in the stock kernel. Is it supposed to be supported? I've not had problems with this in Debian, which has a similar kernel time-line. Thanks for answers and I hope I've stopped someone from banging their head on their keyboard ;) John, I noticed my RHEL6.1 Beta kernel has a *lot* of fixes for USB 3.0 support, so it's quite possible that changing to a newer kernel is a solution to this problem. Unfortunately, in the past these newer (test) kernels were available from Red Hat (they still are for RHEL5) but all of those kernels and projects have disappeared, likely as part of the competition from Oracle and other distributions using Red Hat's backporting efforts to compete with Red Hat. http://people.redhat.com/arozansk/el6/ It's a pity because I used to track those :-( -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
RPMforge changes
Hi, I have to bring the sad news that I forgot to inform this mailinglist of an important change that happened to the RPMforge repositories (I thought I did though). With the release of RHEL6 the base RPMforge repository has been split between packages that do not replace base packages, and packages that do. Not only for RHEL6, but also for RHEL5, RHEL4, RHEL3 and RHEL2. This was something frequently requested, and one of the reasons some people avoided the RPMforge repository. My personal view on this is that such a policy is much better handled by the depsolver (eg. yum) but lacking proper plugins that would allow flexibility the decision was made to split the repository in two. In fact we already had two separate repository, which makes 4 repositories in total: - rpmforge(tag: rf) - additional packages - rpmforge-extras (tag: rfx) - packages replacing base - rpmforge-testing(tag: rft) - test/development packages - rpmforge-buildtools (tag: rfb) - buildtools (only needed for building) The good news is that we now provide RHEL6 packages and that enabling RPMforge by default is safer than ever. Cherry-picking packages from rpmforge-extras is possible by either including specific packages in your yum configuration, or relying on one of the plugins using priorities. The different repotags are used so it becomes very transparent which installed packages replace an official supported upstream package. Again, sorry for omitting this list and the problems this may have caused. Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: TESTING - openafs update for SL5
On Thu, 8 Jul 2010, Troy Dawson wrote: Dag Wieers wrote: On Thu, 8 Jul 2010, Troy Dawson wrote: > With many minor releases, we update the version of openafs for that > minor release. This new version then get's pushed out to the rest of > the releases. > With SL 5.5 we updated openafs to 1.4.12, and we are about to push that > version out to the rest of the SL5 releases. It currently is in > testing, and it has passed every updating test I could think to throw at > it and it updated without any problems. > > We plan on pushing this out on Monday - 12 July 2010 > > To test or update > > SL5 > --- > >yum --enablerepo=sl-testing update kernel-module-openafs\* > > or you can download rpm's by hand at > > http: //ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/openafs/ > http: //ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/openafs/ Would there be any interest if we provided kmod-openafs modules that are kernel-agnostic (or kABI-tracking as we say) from ELRepo ? The advantage is that the modules keep on working through kernel-updates, which makes update-cycles (and maintenance) to be less work. I am tempted to create those packages, but without an interested party that can provide sufficient testing the effort is kinda moot. Let me know, I thought that the openafs kernel modules didn't work well with kABI, but I would love to find that incorrect. If you think it is possible, please build it, and I'm certain we'll have plenty of testers. If that is true we might have a discussion with Red Hat to see whether we can have those symbols as part of the kABI whitelist. Let's find out :-) For SL5, I'd like to stick with what we have with the supported release, but I'm very sure that we would have plenty of users wiling to test and use the kmod-openafs module. If everything goes well, we could offer it as an alternative. For SL6, if this works we could use that and save us from having to create kernel modules with each kernel update. Sure, I don't want to force anyone anyway. A clean upgrade path will be very hard due to the fact that these kernel-module packages have the kernel-version in the name. So your position makes a lot of sense. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Re: TESTING - openafs update for SL5
On Thu, 8 Jul 2010, Troy Dawson wrote: With many minor releases, we update the version of openafs for that minor release. This new version then get's pushed out to the rest of the releases. With SL 5.5 we updated openafs to 1.4.12, and we are about to push that version out to the rest of the SL5 releases. It currently is in testing, and it has passed every updating test I could think to throw at it and it updated without any problems. We plan on pushing this out on Monday - 12 July 2010 To test or update SL5 --- yum --enablerepo=sl-testing update kernel-module-openafs\* or you can download rpm's by hand at http: //ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/openafs/ http: //ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/openafs/ Would there be any interest if we provided kmod-openafs modules that are kernel-agnostic (or kABI-tracking as we say) from ELRepo ? The advantage is that the modules keep on working through kernel-updates, which makes update-cycles (and maintenance) to be less work. I am tempted to create those packages, but without an interested party that can provide sufficient testing the effort is kinda moot. Let me know, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS
Hi, I would like to announce a set of OCFS2 kABI-tracking kernel module packages for RHEL5, Scientific Linux 5 and CentOS-5 and kernels. These packages have been introduced into the ELRepo testing repository (http://elrepo.org/). You can find these packages at: http://elrepo.org/linux/testing/el5/ The ELRepo project is a community project providing various additional kernel modules for Red Hat Enterprise Linux and derivative kernels that aim to be kernel independent. Next to this set of OCFS 1.4.7 kernel modules the project provides dozens of kmod RPM packages and hundreds of kernel modules for a variety of hardware and kernel functionality. In this case we are looking for OCFS2 users willing to test these packages and provide feedback and support in our support channels for future users. We welcome your feedback on our mailinglist and bug-tracker, respectively at: http: //lists.elrepo.org/mailman/listinfo/elrepo http: //elrepo.org/bugs/main_page.php Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Kernel independent DRBD packages for RHEL, CentOS and Scientific Linux
Hi, I would like to announce a set of DRBD kABI-tracking kernel module packages for RHEL5, CentOS-5 and Scientific Linux 5 kernels. These packages have been introduced into the ELRepo testing repository (http://elrepo.org/). You can find these packages at: http://elrepo.org/linux/testing/el5/ The ELRepo project is a community project providing various additional kernel modules for Red Hat Enterprise Linux and derivative kernels that aim to be kernel independent. Next to this set of DRBD 8.3.8 kernel modules the project provides dozens of kmod RPM packages and hundreds of kernel modules for a variety of hardware and kernel functionality. In this case we are looking for DRBD users willing to test these packages and provide feedback and support in our support channels for future users. In case there is interest, we can provide drbd 8.0.16 packages on request. We welcome your feedback on our mailinglist and bug-tracker, respectively at: http://lists.elrepo.org/mailman/listinfo/elrepo http://elrepo.org/bugs/main_page.php Kind regards, -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
