Re: SL 6.4 with OpenVZ kernel: /pre-pivot/50selinux-loadpolicy.sh: 14: cannot create /sysroot/selinux/enforce: Read-only file system
Hi Olivier! Am Sonntag, 19. Mai 2013, 11:16:13 schrieb Olivier Mauras: > Actually OpenVZ installation specifically tells you to > disable SElinux. Seems like you didn't. > On a side note, OpenVZ related > should be redirected to OpenVZ mailing list. Thanks for the hints! I did not know whether this was an SL or a OVZ problem, so I asked here. I now read the following articles again and used the mentioned settings, and the system works well: http://openvz.org/Quick_Installation_CentOS_6 http://wiki.centos.org/HowTos/Virtualization/OpenVZ Best regards, Dennis signature.asc Description: This is a digitally signed message part.
SL 6.4 with OpenVZ kernel: /pre-pivot/50selinux-loadpolicy.sh: 14: cannot create /sysroot/selinux/enforce: Read-only file system
Hello! I am using Scientific Linux 6.4 with an OpenVZ 2.6.32-042stab076.8 kernel. After the usual kernel messages, I will always get this message: [...] [0.018485] PCI: Fatal: No config space access function found /pre-pivot/50selinux-loadpolicy.sh: 14: cannot create /sysroot/selinux/enforce: Read-only file system Welcome tovScientific Linux Starting udev: [ OK ] [...] I also noticed these messages in dmesg: [1.519316] dracut: Loading SELinux policy [1.736227] dracut: /sbin/load_policy: Can't load policy: No such device Are these messages important? How can I fix them? Best regards, Dennis signature.asc Description: PGP signature
Re: Please update vsftpd package
Hi Matthias and everyone else! Am Freitag, 8. Juni 2012, 17:21:42 schrieben Sie: > On 06/08/2012 04:28 PM, Dennis Schridde wrote: > > Am Freitag, 8. Juni 2012, 12:58:53 schrieben Sie: > >> On 06/08/2012 11:27 AM, Dennis Schridde wrote: > >>> The version of the package currently available in SL6 is > >>> vsftpd-2.2.2-6.el6_0.1.x86_64, > > Are you sure about this? in fastbugs I see vsftpd-2.2.2-6.el6_2.1 I haven't had fastbugs enabled and did not check there. Will look there next time I think an update is missing! Thanks for the hint! > > Bug #708657 comment #47 [1] mentions bug #767108 [2] which was closed in > > January. So it appeared to me as if SL was missing a fix from RHEL for 5 > > months. I am sorry if I misunderstood the meaning of the bugreports. > > They can be tricky at times, and I also got confused by the versions > mentioned. Thanks for your explanation! Generally in RHEL, bugfixes are not included in updates for the current release, but only come with the next minor version? If I have non security issues with the current release, I have to enable fastbugs? Kind regards, Dennis signature.asc Description: This is a digitally signed message part.
Re: Please update vsftpd package
Hello everyone! Am Freitag, 8. Juni 2012, 08:44:35 schrieben Sie: > And in this day and age with password sniffing > going on over local networks by zombied machines and happening as a matter > of government policy worldwide in data centers, and the historic firewall > wackiness with FTP's 2 channel communications, *WHY* is your client using > FTP for anything that is password based? You can cross-hook it to normal > logins, true, but this is a really bad idea for basic security reasons and > should be avoided wherever feasible. Thanks for that hint! I just found that old server and decided to move the service onto a new host (and non EOL distro) to integrate it with the rest of the infrastructure (and get security updates). I will suggest to the clients to use another service that is less of a security problem. > Or are they using FTPS? So far I found no client that reliably supports FTPS. Especially nothing that comes with the OS "by default" (I tried Chrome, Firefox, KDE/Dolphin). Can you suggest one? Kind regards, Dennis Schridde signature.asc Description: This is a digitally signed message part.
Re: Please update vsftpd package
Am Freitag, 8. Juni 2012, 12:58:53 schrieben Sie:
> On 06/08/2012 11:27 AM, Dennis Schridde wrote:
> > Hi!
> >
> > The version of the package currently available in SL6 is
> > vsftpd-2.2.2-6.el6_0.1.x86_64, while RHEL6 apparently ships
> > vsftpd-2.2.2-11.el6 [1]. Can you please update it, as it contains a bugfix
> > that is important for our systems.
> >
> > Kind regards,
> > Dennis Schridde
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=708657 ("Fixed In
> > Version")
>
> Please cite properly: "should be fixed in"... and the comment was made
> this night at 03:21:47 EDT.
>
> What makes you believe that RH has released the fix already? What makes
> you think it has already passed QA?
>
> Matthias
Bug #708657 comment #47 [1] mentions bug #767108 [2] which was closed in
January. So it appeared to me as if SL was missing a fix from RHEL for 5
months. I am sorry if I misunderstood the meaning of the bugreports.
Regarding QA: Bug #708657 changed from ON_QA to VERIFIED in April. I assume
that means it passed QA? Again I am sorry if I misunderstood the meaning of
that.
Kind regards,
Dennis Schridde
[1] https://bugzilla.redhat.com/show_bug.cgi?id=708657#c47
[2] https://bugzilla.redhat.com/show_bug.cgi?id=767108
signature.asc
Description: This is a digitally signed message part.
Re: Please update vsftpd package
Am Freitag, 8. Juni 2012, 09:47:48 schrieben Sie: > Per http://rhn.redhat.com/errata/RHBA-2012-0001.html , you should not be > looking for vsftpd-2.2.2-11.el6. I was able to find in a mirror ... > /scientific/6x/x86_64/updates/fastbugs/vsftpd-2.2.2-6.el6_2.1.x86_64.rpm Thanks for that hint! --Dennis signature.asc Description: This is a digitally signed message part.
Please update vsftpd package
Hi!
The version of the package currently available in SL6 is
vsftpd-2.2.2-6.el6_0.1.x86_64, while RHEL6 apparently ships
vsftpd-2.2.2-11.el6 [1]. Can you please update it, as it contains a bugfix
that is important for our systems.
Kind regards,
Dennis Schridde
[1] https://bugzilla.redhat.com/show_bug.cgi?id=708657 ("Fixed In Version")
signature.asc
Description: This is a digitally signed message part.
Red Hat Bug #639280: vte not setting TERM variable for terminal emulators other than gnome-terminal
Hello! It appears to me that Red Hat Bug #639280 [1] against Fedora 14 appears also in Scientific Linux 6.2: E.g. in Guake $TERM is "dumb" instead of "xterm". Can someone confirm this? Is this also a bug in RHEL 6.2? Where should I report it, so it can be fixed soon? Kind regards, Dennis [1] https://bugzilla.redhat.com/show_bug.cgi?id=639280 signature.asc Description: This is a digitally signed message part.
Re: Should yum-autoupdate depend on mailx?
Am Montag, 26. September 2011, 13:25:17 schrieb Pat Riehecky: > We've added mailx as a dependency since it doesn't pull in anything > extra (in terms of mail system packages). It should be in fastbugs > later this week. Thanks a lot! --Dennis signature.asc Description: This is a digitally signed message part.
Re: Should yum-autoupdate depend on mailx?
Am Montag, 19. September 2011, 18:46:25 schrieben Sie: > Am Montag, 19. September 2011, 09:56:47 schrieb Pat Riehecky: > > Adding it shouldn't be too much work, but from the distribution side we > > don't want to force all our users to run a "sending only" mail server > > (or more) unless they actually want to. I might instead add a check in > > the script where, if sending mail doesn't look possible, it simply > > doesn't try to send it. That way people don't have to worry about > > surprise software installation on their next update. I know I'd freak > > out if suddenly my system is running sendmail/postfix when it wasn't > > before. > It does not seem that mailx requires sendmail/postfix (says "rpm -qR > mailx"). So adding the dependency should be safe. Has this info I gave been considerd? Has anything been decided on this issue, yet? --Dennis signature.asc Description: This is a digitally signed message part.
Re: Should yum-autoupdate depend on mailx?
Am Montag, 19. September 2011, 09:56:47 schrieb Pat Riehecky: > On 09/19/2011 08:52 AM, Alec T. Habig wrote: > > Dennis Schridde writes: > >> So it is indeed a bug? How should I progress from here? (I did not see > >> a > >> bugtracker on the website.) > > > > Since very few packages actually belong to SL (as opposed to TUV, who > > have their own bugzilla), we just say on the mailing list: "Hey Connie > > and Pat, here's an easily fixed bug!" > > > > Specifically, please add a mailx dependency to yum-autoupdate. > > > > Low tech but it works :) Reminds me of a "Letterman" cartoon episode, > > > > for example: > >http://www.youtube.com/watch?v=z3y_H3SaoAY&feature=results_video&p > >laynext=1&list=PLBE024B04B63BF3E8 > Adding it shouldn't be too much work, but from the distribution side we > don't want to force all our users to run a "sending only" mail server > (or more) unless they actually want to. I might instead add a check in > the script where, if sending mail doesn't look possible, it simply > doesn't try to send it. That way people don't have to worry about > surprise software installation on their next update. I know I'd freak > out if suddenly my system is running sendmail/postfix when it wasn't before. It does not seem that mailx requires sendmail/postfix (says "rpm -qR mailx"). So adding the dependency should be safe. --Dennis signature.asc Description: This is a digitally signed message part.
Re: Should yum-autoupdate depend on mailx?
Am Samstag, 17. September 2011, 11:20:17 schrieb Alec T. Habig: > Dennis Schridde writes: > > The issue I meant to report was that, even though the files installed > > by autoupdate-2-2.noarch use mailx, the *package* does not depend on > > it. > > It should have this dependency. For yum-cron we did put it in, as some > people with minimal or super-secure installs didn't want to put in > mailx, and then the cron jobs bombed. It's an easy tweak to the spec > file. So it is indeed a bug? How should I progress from here? (I did not see a bugtracker on the website.) --Dennis signature.asc Description: This is a digitally signed message part.
Re: Should yum-autoupdate depend on mailx?
Hello!
Thank you for your reply!
The issue I meant to report was that, even though the files installed by
autoupdate-2-2.noarch use mailx, the *package* does not depend on it.
Kind regards,
Dennis
Am Freitag, 16. September 2011, 15:33:01 schrieb jdow:
> Yum autoupdate sends email to "root" about updates performed. Perhaps
> that is the reason it is looking for mailx. It uses mailx in a scripted
> mode to create the messages.
>
> {^_^}
>
> On 2011/09/16 02:33, Dennis Schridde wrote:
> > Hello!
> >
> > Line 211 of /etc/cron.daily/yum-autoupdate calls /bin/mail, but yum-
> > autoupdate-2-2.noarch does not depend on anything providing that file
> > (mailx-12.4-6.el6.x86_64).
> >
> > This seems like a bug in dependencies, or is there a reason for this?
> >
> > Kind regards,
> > Dennis
signature.asc
Description: This is a digitally signed message part.
Should yum-autoupdate depend on mailx?
Hello! Line 211 of /etc/cron.daily/yum-autoupdate calls /bin/mail, but yum- autoupdate-2-2.noarch does not depend on anything providing that file (mailx-12.4-6.el6.x86_64). This seems like a bug in dependencies, or is there a reason for this? Kind regards, Dennis signature.asc Description: This is a digitally signed message part.
