On 18 Aug 2017 4:42 pm, "Jakub Jelen" <jjelen(a)redhat.com> wrote:
On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> Hello Fedora devels and users,
> more than three years ago, the same topic started discussion if we
> this package in Fedora or not and how . The discussion resulted
> mostly in flames and in the removal of the dependency on tcp_wrappers
> from systemd. But it was quite agreed that it is considered as a
> security layer for some users, if they use it correctly, or something
> that is or should be replaced by firewalls.
> So can we discuss it now once more without the affiliation to
> The fact is that we still do not have any other replacement except
> firewalls. But do we need one?
> The complete removal of the package is probably not a wise step, even
> though we can not find tcp_wrappers in recent SuSE anymore . It is
> still available in Arch  without other tools depending on it. To
> fair, Debian  is still building tools (for example openssh) with a
> build-time support for it.
> My primary concern is OpenSSH, which upstream dropped support for
> tcp_wrappers three years ago (late 2014)  and since then we are
> maintaining one more downstream patch. But this effort should be
> coordinated among other components to simplify the transition for
> who insist on using it (using tcpd).
> Removing the dependency will also allow us to trim the default
> install for few more Kb.
> If there will be no significant drawbacks, I will progress with
> a system wide change for Fedora 28 and I will pull the maintainers of
> other tolls using libwrap into the round and discussion.
In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
Since I'm listed twice in there...
With my packages and the situation with build time options I take the
position of enable as much as possible since our users don't get to pick
their compilation options.
However tcp_wrappers is a legacy thing that no longer belongs in today's
I have no objection to a flag day in F28 development and dropping the build
option at some point, preferably before the thing that is no longer an
alpha ;) ... ie way before beta.
As for downstream ... well we're Fedora. If Red Hat want it still in RHEL8
that's up to them and they can maintain the downstream patches in their
Would it be possible to make [dnf update] output something immediately after being run? And what would be the right course of action to get this feature implemented? I know it's probably a miniscule thing, but it's one of those small details you notice when shifting over from an apt-based distro. When running [apt update] or [apt upgrade] it responds instantly.
I usually run it like [sudo dnf update] and when you mistype your password it gives you a wait period, but so does [dnf update]. So in a brief moment you're left hanging not knowing whether the password was incorrect or if [dnf] is simply updating. I know changing [sudo] to not give a wait period would be a lesser crime to some, so therefore I'm wondering if we can change [dnf] instead.
If I'm addressing the wrong list, please advise. Also I'm not very good at C languages so I can't just provide a patch unfortunately.
I've got a Fedora 26 desktop that logs the following each hour
gsd-housekeepin: Failed to enumerate children of /tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-fwupd.service-hqduB4: Error opening directory '/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-fwupd.service-hqduB4': Permission denied
gsd-housekeepin: Failed to enumerate children of /tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-colord.service-xLGvFD: Error opening directory '/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-colord.service-xLGvFD': Permission denied
gsd-housekeepin: Failed to enumerate children of /tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-tor.service-4wY1IF: Error opening directory '/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-tor.service-4wY1IF': Permission denied
gsd-housekeepin: Failed to enumerate children of /tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-named.service-MvF69U: Error opening directory '/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-named.service-MvF69U': Permission denied
gsd-housekeepin: Failed to enumerate children of /tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-rtkit-daemon.service-Hn3mJ1: Error opening directory '/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-rtkit-daemon.service-Hn3mJ1': Permission denied
gsd-housekeepin: Failed to enumerate children of /tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-chronyd.service-VT0jSC: Error opening directory '/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-chronyd.service-VT0jSC': Permission denied
gsd-housekeepin: Failed to enumerate children of /tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-httpd.service-ZLBoQC: Error opening directory '/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-httpd.service-ZLBoQC': Permission denied
gsd-housekeepin: Failed to enumerate children of /var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-httpd.service-q9X35G: Error opening directory '/var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-httpd.service-q9X35G': Permission denied
gsd-housekeepin: Failed to enumerate children of /var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-colord.service-wH5kHY: Error opening directory '/var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-colord.service-wH5kHY': Permission denied
gsd-housekeepin: Failed to enumerate children of /var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-fwupd.service-ZBwFva: Error opening directory '/var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-fwupd.service-ZBwFva': Permission denied
gsd-housekeepin: Failed to enumerate children of /var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-tor.service-pfoLAy: Error opening directory '/var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-tor.service-pfoLAy': Permission denied
gsd-housekeepin: Failed to enumerate children of /var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-named.service-lgdjRM: Error opening directory '/var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-named.service-lgdjRM': Permission denied
gsd-housekeepin: Failed to enumerate children of /var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-rtkit-daemon.service-md0RhP: Error opening directory '/var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-rtkit-daemon.service-md0RhP': Permission denied
gsd-housekeepin: Failed to enumerate children of /var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-chronyd.service-AfsMsq: Error opening directory '/var/tmp/systemd-private-2d0347e0be4b43bfb6fca3b1677bd2ef-chronyd.service-AfsMsq': Permission denied
The timestamp on those directories is the same as the last boot and the permissions are drwx------. 3 root root
What's the problem and how can I fix it?
The manpage for the fedora csh describes the usage of goto,
but it does not work.
Anyone with insight on this?
If you CAN make it work, please provide
a skeleton of the script where the label
is visible and the goto statement is visible :)
I found many references to similar problems but none are suitable in my case.
I know that I am using an old video card but it is understood to be supported. I think that the problem
is in the way the server starts and may be easy to work around. Details below.
The symptom is this:
- I start the computer (cold start)
Waking up from a hibernation does not have a problem
- I am presented with a login screen, and use it
- the screen freezes, no keyboard or mouse <<<<< the problem
- I kill Xorg (ssh from another machine) <<<<< the current ugly fix
- I am presented with a login screen, and use it
- my session starts and all is well
I investigated the matter and now think that I see a problem.
First, /var/log/Xorg.1.log (from the first attempt) ends with
[ 35.865] (II) NVIDIA(0): NVIDIA GPU GeForce 8600 GT (G84) at PCI:1:0:0 (GPU-0)
[ 35.865] (--) NVIDIA(0): Memory: 524288 kBytes
[ 35.865] (--) NVIDIA(0): VideoBIOS: 60.84.59.00.00
[ 35.865] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[ 35.869] (EE) NVIDIA(GPU-0): EVO Push buffer channel allocation failed
[ 35.872] (EE) NVIDIA(GPU-0): Failed to allocate EVO core DMA push buffer
[ 35.873] (EE) NVIDIA(0): Failing initialization of X screen 0
[ 35.874] (EE) Server terminated with error (1). Closing log file.
(and I think that this is where the freeze comes from).
The second attempt shows no error. Looking at the timestamps one sees this:
1st 19.310- 35.891 35.764- 35.874
[35.869] (EE) NVIDIA(GPU-0): EVO Push buffer channel allocation failed
2nd 502.160-516.936 517.023-519.530
It is clear that in the first attempt the second session starts (and fails) before the first one exits.
In the second case there is no overlap.
Is it possible that the overlap causes the error? Where can I put a (small) delay to test this
proposition and avoid the overlap? Or is there another way to avoid it?
I am on f26, using xfce wm (not that this should matter?). The driver:
(II) NVIDIA GLX Module 340.102 Mon Jan 16 12:37:38 PST 2017
(II) NVIDIA dlloader X Driver 340.102 Mon Jan 16 12:17:09 PST 2017
$ dnf list installed '*nvidia*'
akmod-nvidia-340xx.x86_64 1:340.102-4.fc26 @@commandline
kmod-nvidia-340xx-4.11.10-100.fc24.x86_64.x86_64 1:340.102-4.fc26 @@commandline
kmod-nvidia-340xx-4.11.12-100.fc24.x86_64.x86_64 1:340.102-4.fc26 @@commandline
kmod-nvidia-340xx-4.12.5-300.fc26.x86_64.x86_64 1:340.102-4.fc26 @@commandline
xorg-x11-drv-nvidia-340xx.x86_64 1:340.102-1.fc26 @@commandline
xorg-x11-drv-nvidia-340xx-kmodsrc.x86_64 1:340.102-1.fc26 @@commandline
xorg-x11-drv-nvidia-340xx-libs.x86_64 1:340.102-1.fc26 @@commandline
xorg-x11-drv-nvidia-kmodsrc.x86_64 2:375.66-7.fc26 @@commandline
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)
If you use balsa, in Fedora 26 you may have trouble sending mail
(see Bug 1479177 - since upgrade balsa is no longer able to send
balsa uses libesmtp to send the mail, but libesmtp was accidentally
built without SSL support (fixed in my Bug 1483350 - libesmtp built
w/o SSL support -- compat-openssl10 required). balsa itself
should also be built for compat-openssl10.
In the past (e.g., F20 that I upgraded from) a mail server with a
self-signed certificate was accepted, but is now rejected with a
useless error message. I think that a self-signed cert is OK for
submitting email as it is only used to keep the data (and your
password) private (fixed in my Bug 1483649 - balsa no longer accepts
mail server self-signed certificate).
When composing a message, the toolbar Queue button sends immediately
instead of queuing (fixed in my Bug 1483354 - balsa message window
Queue toolbar button sends immediately).
I'm running F26/x86_64 and having the following problem: In earlier
Fedora Versions, I could use PageUP or PageDown key to scroll through
the gnome-terminal output (or I could use the mouse wheel for doing the
same). But in F26, nothings happens if I use these keys or the mouse
wheel! Anybody knows whether this feature has been been abolished in F26?
Fedora release 26 (Twenty Six)
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
On Fri, 2017-08-18 at 13:15 -0500, Jason L Tibbitts III wrote:
> For the record, denyhosts currently relies upon the tcp_wrappers
> functionality in openssh to function. While it's possible to make it
> manipulate the firewall as well, the whole situation is kind of a
> (Does it talk to firewalld? What if you're not running firewalld?)
Unfortunately this is not as straightforward as it could be.
Checking how Archlinux does it now, they probably go without denyhosts.
There is a also a tool sshguard , which does quite much the same as
fail2ban using configurable backend (firewalld, iptables, ...).
The denyhosts got last update also 10 years ago  and we already have
quite much 2 alternatives that can do the same using firewalls, so it
might be also a time to go for denyhosts. Or not, but clearly document
that OpenSSH will not be using hosts.deny anymore.
> Sadly I know how terrible tcp_wrappers is and so I know it needs to
> away. It's just unfortunate that there's no replacement for it
> firewalling, and dealing with the firewall is unfortunately so
> So that's three of my packages that use tcp_wrappers in some way
> (denyhosts, apcupsd and cyrus-imapd) though I suspect two of those
> need the build dependencies dropped.
That would be great if you could review the dependencies if it is used
and drop the bogus dependencies.
Red Hat, Inc.
Some years ago, I bought an
IBM-refurbished Thinkpad T42, meaning to
devote it to use with a Garmin UPS, under
Linux of course. It turned out not to be
suitable for that.
I put it into the guest room, where
it also got little or no use. Until last
week, it still had Fedora 22. I've been
trying for days to get F26, or 25, or even
24 onto it.
It demanded an i386, 32-bit .iso;
and I did finally manage, after a lot of
grief, to get it to seem to finish an
installation. Upon rebooting, it says only
that it can't boot what it has!
As a last resort, I've been looking
for a Puppy Linux version. The download
page offers versions for Ubuntu (which
affects me like sand in the teeth),
Slackware (which I've never even seen
running), and M$. Oh, and also for the
Is there hope??
Beartooth Staffwright, PhD, Neo-Redneck Linux Convert
What do they know of country, who only country know?
For the t42 you need to tweak one kernel parameter.
T42-CPU does not support pae-extension.
Somewhere down the kernel-line they changed the default setting. From default to 'required', thus very old cpu's won't boot anymore, unless you drop this requirement.
Sent from my iPhone
> On 18 Aug 2017, at 23:10, Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
>> On Fri, 2017-08-18 at 10:55 -0700, Rick Stevens wrote:
>> Do you remember when Gates said we'd never need more than 64K of RAM?
> It was 640K, but yeah. Of course I ran a 12-user PDP-11/45 with 256K of
> RAM, but that was then.
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.