requests for root password
by Fulko Hew
As a result of a recent update, I now see authentication requests for
the root password whenever:
a) the software update daemon wakes up to check for updates (or to
install what it finds)
b) when I plug in a USB mass storage device
How can this be turned off again ?
TIA
Fulko
6 years, 7 months
Re: tcp_wrappers deprecation
by James Hogarth
On 24 August 2017 at 10:33, Peter Robinson <pbrobinson(a)gmail.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.
>
> With F-27 now branched off this can happen in F-28/rawhide now
> _______________________________________________
>
>
Indeed ... it's a great time to do so ... but let's carry it out under the
auspices of a System Wide Change for F28 :)
6 years, 7 months
Issues burning files to DVD -- Fedora 26
by Terry Polzin
Has anyone had difficulties burning files to DVD?
I am trying to burn pictures I imported from my phone with XFBURN and after
what appears to be a successful burn, the DVD does not show anything on it.
Thanks,
Terry
6 years, 7 months
python-sipsimple
by Kseniya Blashchuk
Has anybody had a chance to install python-sipsimple on fedora 26? I would
like to use Blink SIP client but I have faced some troubles with building
python-sipsimple. Does anybody have any ideas?
6 years, 7 months
Re: tcp_wrappers deprecation
by James Hogarth
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.
6 years, 7 months
DNF suggestion
by Daniel Ståhl
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
6 years, 7 months
gsd-housekeepin[2202]: Failed to enumerate children of
by mark2015@openmailbox.org
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
6 years, 7 months
the fedora csh and goto
by JD
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.
6 years, 7 months
problem starting X
by Eyal Lebedinsky
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)
6 years, 7 months