users August 2017

users@lists.fedoraproject.org

126 participants
115 discussions

Re: tcp_wrappers deprecation
by James Hogarth 24 Aug '17

24 Aug '17

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 > want > this package in Fedora or not and how [1]. 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 > systemd? > 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 [2]. It is > still available in Arch [3] without other tools depending on it. To > be > fair, Debian [4] 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) [5] and since then we are > maintaining one more downstream patch. But this effort should be > coordinated among other components to simplify the transition for > users > 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 > filling > a system wide change for Fedora 28 and I will pull the maintainers of > other tolls using libwrap into the round and discussion. Hello, In Fedora 26, there is over 50 packages using tcp_wrappers as a build- time dependency: 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 world. 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 distro still.

1 0

DNF suggestion
by Daniel Ståhl 23 Aug '17

23 Aug '17

Hi, 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. -- Ds

5 6

gsd-housekeepin[2202]: Failed to enumerate children of
by mark2015＠openmailbox.org 23 Aug '17

23 Aug '17

I've got a Fedora 26 desktop that logs the following each hour gsd-housekeepin[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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[2202]: 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? /Mark

2 1

the fedora csh and goto
by JD 22 Aug '17

22 Aug '17

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 :) Thanx.

7 17

problem starting X
by Eyal Lebedinsky 21 Aug '17

21 Aug '17

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: Xorg.0.log Xorg.1.log 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 TIA -- Eyal Lebedinsky (fedora(a)eyal.emu.id.au)

2 3

F26: balsa users having trouble sending mail?
by Tony Nelson 21 Aug '17

21 Aug '17

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 emails[1]). 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[2]). 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[3]). 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[4]). [1]: <https://bugzilla.redhat.com/show_bug.cgi?id=1479177> [2]: <https://bugzilla.redhat.com/show_bug.cgi?id=1483350> [3]: <https://bugzilla.redhat.com/show_bug.cgi?id=1483649> [4]: <https://bugzilla.redhat.com/show_bug.cgi?id=1483354> -- ____________________________________________________________________ TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>

1 0

Usage of PageUp/Page Down Key in gnome-terminal
by Joachim Backes 21 Aug '17

21 Aug '17

Hi guys, 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? Kind regards Joachim Backes -- Fedora release 26 (Twenty Six) Kernel-4.12.8-300.fc26.x86_64 Joachim Backes <joachim.backes(a)rhrk.uni-kl.de> https://www-user.rhrk.uni-kl.de/~backes/

6 8

Re: tcp_wrappers deprecation
by Jakub Jelen 21 Aug '17

21 Aug '17

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 > mess. > (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 [1], which does quite much the same as fail2ban using configurable backend (firewalld, iptables, ...). The denyhosts got last update also 10 years ago [2] 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 > go > away. It's just unfortunate that there's no replacement for it > besides > firewalling, and dealing with the firewall is unfortunately so > complicated. > > 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 > just > need the build dependencies dropped. That would be great if you could review the dependencies if it is used and drop the bogus dependencies. [1] https://wiki.archlinux.org/index.php/sshguard [2] https://sourceforge.net/projects/denyhosts/files/ Thanks, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc.

1 0

OS for Thinkpad T42??
by Beartooth 20 Aug '17

20 Aug '17

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 eeePC. Is there hope?? -- Beartooth Staffwright, PhD, Neo-Redneck Linux Convert What do they know of country, who only country know?

10 12

Re: OS for Thinkpad T42??
by J.Witvliet＠mindef.nl 19 Aug '17

19 Aug '17

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. > > poc > _______________________________________________ > 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.

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →