Re: DNS/DHCP problems
Hi, i use dnsmasq for a simple LAN to provide dhcp and dns, to start with it did not work as i did not open the correct ports in the firewall. UDP 67 and 68, as mentioned in the FAQ. I also have the trusted DNS service 53/tcp and 53/udp enabled i not sure if this is necaccery. http://www.thekelleys.org.uk/dnsmasq/docs/FAQ This new DHCP server is well and good, but it doesn't work for me. What's the problem? jon On Wed, 2011-10-05 at 16:42 -0500, ~Stack~ wrote: On 10/05/2011 02:23 PM, Alec T. Habig wrote: In a similar situation (although I don't PXE boot anything anymore) I use the dnsmasq package - it combines the basic functions of dhcp and dns servers with a whole lot less complexity: I looked into dnsmasq but the only way I could get it to work was to manage /etc/ethers and /etc/hosts manually. Then once I had it going, it was rather slow. Maybe I did something wrong and I should revisit it. How do you manage dnsmasq? Manually for every client? Thanks for your input. I do appreciate it! ~Stack~
Showing hostname on the gnome up toolbar
Hi all,
Somebody knows how can I configure up gnome toolbar to show the
hostname near sound and clock preferencies?? (It is a SL6.1 laptop).
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Flash plugin
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
file /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png 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
file /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png 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
file /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png 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
file /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png 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
file /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png 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
file /usr/share/kde4/services/kcm_adobe_flash_player.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
{o.o}
Re: Flash plugin
Hi jdow! On 2011.10.06 at 05:05:05 -0700, jdow wrote next: Date: Thu, 06 Oct 2011 05:05:05 -0700 From: jdow j...@earthlink.net 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.. -- Vladimir
Re: Flash plugin
I did encounter a problem with the official adobe repo yesterday - it wanted to install the i386 version over the x86_64 version, so bombed with a file conflict. Deleting the adobe yum config rpms and relying on Dag made things work here. -- Alec Habig, University of Minnesota Duluth Physics Dept. ha...@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/
Re: Flash plugin
Hi Dag Wieers! On 2011.10.06 at 16:38:04 +0200, Dag Wieers wrote next: 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. Yes, well, I meant when final 11 release will appear in rpmforge (like it is now in official repo). OK, according to you it's best to just wait a bit. -- Vladimir
Completed Distribution Servers Downtime - 30 minutes on Oct 6 2011 9:00 CDT
Hello, The distribution servers are back on line now. We apologize for the unexpected extra downtime on ftp1.scientificlinux.org. Pat On 10/04/2011 10:02 AM, Patrick Riehecky wrote: Hello, The distribution servers rsync.scientificlinux.org, ftp.scientificlinux.org, ftp1.scientificlinux.org, and ftp2.scientificlinux.org will be going down on: Thursday October 6, 2011 at 09:00am CDT (Chicago) Affected Machines: * rsync.scientificlinux.org * ftp.scientificlinux.org * ftp1.scientificlinux.org * ftp2.scientificlinux.org Begin Downtime: October 6, 2011 at 09:00am CDT (Chicago) The downtime is expected to last for 30 minutes. End Downtime: October 6, 2011 at 09:30am CDT (Chicago) For your local time you can run date -d '2011-10-06 09:00 CDT' Thank you for your patience while we perform this maintenance. Pat Riehecky -- Pat Riehecky Scientific Linux Developer
Re: Flash plugin
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). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge a.c.aitchi...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
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 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. I face the same problem, and thus attempt to keep a 32 bit Firefox installed, non-distro but straight from Mozilla, and use the 32 bit plugins, etc. This presents the additional issue of keeping all of the needed 32 bit .so libraries, etc., in place. 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. Yasha Karant
Re: Flash plugin
On Thu, 2011-10-06 at 19:08 +0200, Dag Wieers wrote: So, why would one replace a 64bit flash-plugin with a 32bit one ? If the 64bit version was used, it simply would have worked. I originally installed the 32 bit version from adobe and then updated to the 64 bit from the repo. Now, every time adobe updates the version, it appears as an update. The solution is to remove or disable the adobe repo.
Re: Cannot install downloaded updates and dual boot issue
On 10/05/2011 07:34 AM, Urs Beyerle wrote: Hi, On 10/04/2011 11:34 PM, Connie Sieh wrote: On Tue, 4 Oct 2011, Sean Nelson wrote: Hello, I just installed SL6 from the Live CD and I'm having two post install issues. 1) I am unable to complete my initial update. Whenever I run 'sudo yum update' the updates download fine but will not install. I recieve this error: --- Install 2 Package(s) Upgrade 123 Package(s) Total size: 172 M Is this ok [y/N]: y Downloading Packages: warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY Public key for openvpn-2.2.1-1.el6.x86_64.rpm is not installed --- My question is, where do I get this GPG key, and others assuming they come up? This is the EPEL key. It should be in /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6 . Where did you get openvpn-2.2.1-1.el6.x86_64.rpm from? It's a LiveCD issue. Openvpn is included on the LiveCD and should be updated over the LiveCD extra repository. As a workaround edit as root the file /etc/yum.repos.d/livecd-extra.repo and add the line gpgcheck=0 I have to think about how to fix this bug. The problem should be solved now. You don't have to add gpgcheck=0 anymore. Just run twice yum update after a LiveCD/DVD installation. Thanks for reporting this. Cheers, Urs
Re: Flash plugin
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.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. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge a.c.aitchi...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
Re: Flash plugin
On 2011/10/06 07:38, Dag Wieers wrote:
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 j...@earthlink.net
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.
That is entirely true. Now, I need to convince yum update of this pesky
detail.
(And sorry about tracking down which repo I got it from. I stopped too soon
on the version and literally didn't see the .rf in there. My bad.)
The problem is that yum update insists I need the 32 bit version of the
flash plugin.
{^_-}
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.
Re: Flash plugin
On 2011/10/06 13:12, 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.
And even an explicit yum update flash-plugin.x86_64 still tries to update
the .i386 version. I disabled the adobe repo. That seems to sort of fix it.
Now, I hope the 64 bit version updates properly. (Of course, I seldom use
the browser on that particular machine. Lately I've been using it to stream
some background music for the room. Otherwise I'd have never bothered with
the flash plugin. KUSC and K-Mozart are unlikely to be sources of 'ix type
nasties. So I figure I'm safe.)
{^_^}
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 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. Yasha Karant
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, 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 bythe 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 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 7 October 2011 00:37, Dag Wieers d...@wieers.com wrote: 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. Hi Dag, I strongly suspect that there are certain people posting to this list who are still new to the RHEL product ethos and, thus, that of its clones. As you know, the recommended reading for those persons starts with the following Red Hat policy regarding the backporting of security fixes -- http://www.redhat.com/security/updates/backporting/ Regards, Alan.
Re: Flash plugin
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. Since EL/SL has a custom rolled 64-bit version now, there is no need to use the Adobe repo (other than for the reader), so disable the repo after installing the reader. (It does some things better than evince, so you may need it occasionally.)
Re: Flash plugin
On Fri, 2011-10-07 at 00:58 +0100, Alan Bartlett wrote: As you know, the recommended reading for those persons starts with the following Red Hat policy regarding the backporting of security fixes -- http://www.redhat.com/security/updates/backporting/ Perhaps it's a tribute to the rise in the distro popularity that many users expect EL to have the same features as the more popular desktop user oriented Ubuntu or Fedora distros, say. ... Together with the fact that the modern Linux user expects it all to work without any self help or understanding of what goes on behind the scenes.
Re: Flash plugin
On 10/06/2011 04:37 PM, Dag Wieers wrote: 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. 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) Thus, although I have been unable to find the vulnerability list (for some reason, more info does not give the details but just does nothing), Mozilla identifies this plugin as vulnerable, presumably a security issue. As a test, I will reload the plugin just in case there is a problem with the Mozilla identification and the vulnerable warning goes away. Just did that: Shockwave Flash Shockwave Flash 11.0 r1 11.0.1.0 is now up to date and the actual package was: flash-plugin-11.0.1.152-release.i386.rpm from macromedia.com As a test, I restarted Firefox and went to http://www.adobe.com/software/flash/about/ that responded that the current Flash plugin is functioning (You have version 11,0,1,152 installed was displayed). Note that I am running IA-32 Firefox on SL 6.1 X86-64, with all necessary compatibility (IA-32) libraries installed in a different path than the X86-64 libraries. (As to the other respondent, I have read and am familiar with TUV policy in https://access.redhat.com/security/updates/backporting/ . I do not necessarily agree with this policy.) Yasha Karant
Re: unattended installation from DVD
On Wed, Oct 5, 2011 at 6:01 PM, William Scott will...@magicwilly.info wrote: On 5 October 2011 20:27, Kevin Wood kevin_v_w...@yahoo.com wrote: This came up a while ago. Full saga is here... http://listserv.fnal.gov/scripts/wa.exe?A2=ind1108L=SCIENTIFIC-LINUX-USERSD=0I=-3P=11276 Hmm. Did you try simply excluding NetworkManager? I've found it to be a maintenance nightmare with unannounced and unplanned changes, interfering with normal DHCP operations, standard server configurations, and VPN setups haphazardsly. Ripping it out entirely is one of my favorite steps for stabilizing a server or desktop setup. It can have its uses in laptop or traveling configurations but it's hardly worth for anything but a frequently laptop with multiple network setups in the same physical locaitons.
Re: Cannot install downloaded updates and dual boot issue
On Wed, Oct 5, 2011 at 1:34 AM, Urs Beyerle urs.beye...@env.ethz.ch wrote: Hi, On 10/04/2011 11:34 PM, Connie Sieh wrote: On Tue, 4 Oct 2011, Sean Nelson wrote: Hello, I just installed SL6 from the Live CD and I'm having two post install issues. 1) I am unable to complete my initial update. Whenever I run 'sudo yum update' the updates download fine but will not install. I recieve this error: --- Install 2 Package(s) Upgrade 123 Package(s) Total size: 172 M Is this ok [y/N]: y Downloading Packages: warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY Public key for openvpn-2.2.1-1.el6.x86_64.rpm is not installed --- My question is, where do I get this GPG key, and others assuming they come up? This is the EPEL key. It should be in /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6 . Where did you get openvpn-2.2.1-1.el6.x86_64.rpm from? It's a LiveCD issue. Openvpn is included on the LiveCD and should be updated over the LiveCD extra repository. As a workaround edit as root the file /etc/yum.repos.d/livecd-extra.repo and add the line gpgcheck=0 I have to think about how to fix this bug. It's from EPEL? If the live CD installs the epel-release package, you should be able to say yum reinstall epel-release --nogpg. I just went through this with a site that installs an epel.repo file, but not the epel-release packae, as part of their base install. The --nogpg option is helpful for any package obtained from a repository where you haven't installed the keys, but you have confidence in its source. Very handy for local RPM testing.
Re: DNS/DHCP problems
Hello again everyone! After quite a bit of reading and thought I came to the conclusion that no matter how I did this project, I am stuck with having multiple subnets on one group of switches (I can't easily pull those apart). This means that I am going to have to maintain a list of MAC addresses/names/IP's somewhere just to differentiate between the servers, dev hosts, and the PXE booted hosts. Therefore it doesn't matter if it is maintained in DNSMasq or BIND/dhcpd. I have been doing some reading on DNSmasq today and attempting to get it working (since there appears to be several willing sources of help who use DNSMasq). I think I made significant progress today, but I still have a few issues and while I read the sections on PXE booting I have not yet attempted it (due to one of the problems listed below). The how is below but for those who just want to jump into it, my questions are these: 1) Do I need to create a dhcp-host entry for every hard set host on the 10.1.1.x network? 2) When I set the tag for the pxeboot group, it was not honored by the DHCP. Why? 3) My FQDN does not seem to be working properly and I am not sure why. Any thoughts on what to try? Here is what I have done: The server is named network1.project.local . * Standard install process using the default install GUI for SL 6.1. * Set network settings as follows IP: 10.1.1.10 Netmask: 255.255.0.0 Gateway:10.1.0.1 (the switches) DNS servers: 10.1.1.10 (in theory anyway) Search domains: project.local * Minimal install that pulls 242 packages From the 6.1 DVD I manually installed dnsmasq and firewall editor. `rpm -ivh dnsmasq-2.48-4.el6.i686.rpm system-config-firewall-tui-1.2.27-3.el6_0.2.noarch.rpm` I modified the firewall so that /etc/sysconfig/iptables now looks like: :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 67 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 68 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 69 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT I modified the /etc/dnsmasq.conf file (ran `sed -e '/^#/d' -e '/^$/d'` to strip out the excess) so it looks like this: domain-needed domain=project.local dhcp-range=devbox,10.1.2.1,10.1.2.255,255.255.0.0,12h dhcp-range=pxeboot,10.1.3.1,10.1.3.255,255.255.0.0,12h log-queries log-dhcp I modified /etc/dnsmasq.d/dev.hosts to include: dhcp-host=08:00:27:c3:a5:0b,set:devbox,Dev1,12h I modified /etc/dnsmasq.d/pxe.hosts to include: dhcp-host=08:00:27:7a:de:28,set:pxeboot,PXE1,12h I figured I would split them now before I started adding in all the other hosts. Should make it simpler later on. service iptables restart service dnsmasq restart DNSMasq threw a message dnsdomainname: Host name lookup failure. I am not sure this is the proper fix, but I just did a `echo 10.1.1.10 network1.project.local network1 /etc/hosts` and the problem went away... This brings me to the first question: Do I need to create a dhcp-host entry for every hard set host on the 10.1.1.x network? Was this just a special case? I have a feeling I might have to. I wasn't planning on having the server range DHCP'd but since it would be statically set on the host I guess I dont see a reason why it couldn't be DHCP on the host and statically set in the DNSMasq settings. Just not sure how to handle the entries in DNSMasq and would like some input. First host; Dev1.project.local. From here I did an install on the host with the network card that matched the MAC address for Dev1. It gets a DHCP IP address of 10.1.2.3. On the host network1 I can `ping Dev1` and I can `ping Dev1.project.local`. On the host Dev1 I can `ping Dev1` but I can not `ping Dev1.project.local`. :-/ Dev1 can not `ping network1` or `ping network1.project.local`. Hrm. More on this later. Second host; PXE1. Same setup as the laste using the host with the network card that matched the MAC address for PXE1. It got an IP address of 10.1.2.1...Err...That should have been in the 10.1.3.x range...So I went back to the man pages for dnsmasq ( web viewable [1] ). Under the -G, --dhcp-host section it seems to me that my configuration should work, right? This is my second question: When I set the tag for the pxeboot group, it was not honored by the DHCP. Why? [1] http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html Well until I can get that sorted, I am not going to try the tftpd mode of DNSMasq. It *looks* promising and a lot easier then the method I was initially going for. I am kinda excited to dig in, but I can't until I get
Re: Flash plugin
On 2011/10/06 17:22, Yasha Karant wrote:
On 10/06/2011 04:37 PM, Dag Wieers wrote:
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.
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)
Thus, although I have been unable to find the vulnerability list (for some
reason, more info does not give the details but just does nothing), Mozilla
identifies this plugin as vulnerable, presumably a security issue.
As a test, I will reload the plugin just in case there is a problem with the
Mozilla identification and the vulnerable warning goes away.
Just did that:
Shockwave Flash
Shockwave Flash 11.0 r1 11.0.1.0 is now up to date
and the actual package was:
flash-plugin-11.0.1.152-release.i386.rpm from macromedia.com
As a test, I restarted Firefox and went to
http://www.adobe.com/software/flash/about/ that responded that the current Flash
plugin is functioning (You have version 11,0,1,152 installed was displayed).
Note that I am running IA-32 Firefox on SL 6.1 X86-64, with all necessary
compatibility (IA-32) libraries installed in a different path than the X86-64
libraries.
(As to the other respondent, I have read and am familiar with TUV policy in
https://access.redhat.com/security/updates/backporting/ . I do not necessarily
agree with this policy.)
Yasha Karant
The downside of that direct approach is that the world gets messy when you want
to move to 7 someday. The direct applications of FireFox and Flash might cause
some form of update conflict you'd get to resolve.
Thanks to the person who mentioned the adobe x86_64 repo. I simply copied the
.i386 file and judiciously renamed a couple lines in the new file. Works fine.
I didn't find one when I looked for it.
{^_-} Joanne
