Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

I would like to mention that DE spins are very important with regard to the ARM7 arch. Gnome shell may or might not be working in arm so kde and the other DE spins are really important. Mostly kde from a QA perspective. As a primary architecture I feel this deserve extra considering. Arm QA is base

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

On Thu, Mar 20, 2014 at 12:40 PM, Bastien Nocera wrote: > - Original Message - > > Workstation might implement easy installation of alternative desktops in > > the GNOME Software app at some point. > > Urgh. This is just moving the problem from the installer/media selection > to the > sof

Re: fail2ban + firewalld suggestions needed

On 03/20/2014 01:12 PM, Matthew Miller wrote: > On Thu, Mar 20, 2014 at 12:17:46PM -0400, Przemek Klosowski wrote: > fail2ban-server - core components with minimal deps > fail2ban-firewalld - firewalld support/configuration - requires firewalld > fail2ban-hostsdeny - tcp_wrappers hosts.

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Fri, 21 Mar 2014, Lennart Poettering wrote: I mean, in this day and age we should not consider an ACL language well designed if it basically pushes users to use IDENT and DNS for authentication. (And no, don't say the words DNSSEC, nobody sets that up, we don't have it as default, and tcpwrap

Re: fail2ban + firewalld suggestions needed

On Thu, Mar 20, 2014 at 8:54 AM, Jonathan Underwood < jonathan.underw...@gmail.com> wrote: > On 20 March 2014 13:04, Richard Shaw wrote: > > On Wed, Mar 19, 2014 at 10:57 PM, Orion Poplawski > > wrote: > >> > >> On 03/19/2014 09:10 PM, Richard Shaw wrote: > >> > Ok using Jonathan's suggestion fo

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 20:04, Martin Langhoff (martin.langh...@gmail.com) wrote: > On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering > wrote: > > > A firewall has mechanisms to filter for all domains, however only > > covering a smaller number of generic, low-level matches and actions. > > > > From

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

Am 21.03.2014 01:17, schrieb Lennart Poettering: > On Thu, 20.03.14 20:55, Hans de Goede (hdego...@redhat.com) wrote: >> So offer something with equivalent functionality (and config file >> syntax compatibility), with a nice modern clean API and then systemd >> and others can be moved over to tha

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 20:55, Hans de Goede (hdego...@redhat.com) wrote: > > I mean, I really don't mind that tcpd/tcpwrap stays in the archives, if > > people want to make use of that. I am simply proposing to not link > > agains them anymore for everything that is in the default system. > > So as an

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, Mar 20, 2014 at 8:04 PM, Martin Langhoff wrote: > On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering > wrote: > >> A firewall has mechanisms to filter for all domains, however only >> covering a smaller number of generic, low-level matches and actions. >> > > From a usability PoV, /etc/h

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering wrote: > A firewall has mechanisms to filter for all domains, however only > covering a smaller number of generic, low-level matches and actions. > >From a usability PoV, /etc/hosts.{allow,deny} is good. I wonder if teaching firewalld to support

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

Am 21.03.2014 01:00, schrieb Lennart Poettering: > On Thu, 20.03.14 13:44, Stephen John Smoogen (smo...@gmail.com) wrote: > >>> Well, all mails servers as well as sshd have much better ways to do >>> such filtering. sshd has "Match", Postfix for example has >>> "smtpd_client_restrictions=", and

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 13:44, Stephen John Smoogen (smo...@gmail.com) wrote: > > Well, all mails servers as well as sshd have much better ways to do > > such filtering. sshd has "Match", Postfix for example has > > "smtpd_client_restrictions=", and so on. > > > And now I need to have X number applicati

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 20:36, Florian Weimer (f...@deneb.enyo.de) wrote: > > OpenSSH can do this on its own without involving tcpwrap: > > > > https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Match_keyword.html > > > > It sounds like a much better choice to stick to that instead

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, Mar 20, 2014 at 10:48:53PM +0200, Oron Peled wrote: > > On Thursday 20 March 2014 19:45:32 Lennart Poettering wrote: > > No. systemd is not a firewall. It currently supports libwrap checks for > > socket activated services. And I'd really like to get rid of that... > > Confession: I've ne

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Mar 20, 2014, at 12:31 PM, Martin Langhoff wrote: > On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering > wrote: > I wonder whether it wouldn't be time to say goodbye to tcpwrappers in > Fedora. There has been a request in systemd upstream to disable support > > As Stephen points out, they

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

2014-03-20 20:55 GMT+01:00 Hans de Goede : > Lennart says: > 1) It is horrible code > 2) It really really is horrible horrible code > 3) And there are other ways to achieve the same goal, so lets kill it > > Others say: > 1) There may be other ways but non so easily central managed with with > a u

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, Mar 20, 2014 at 03:50:07PM -0400, Matthew Miller wrote: > it's time for it to go now, I think it's reasonable to declare it deprecated > for F21, with release notes, warnings in hosts.allow and hosts.deny, updates And by "declare", I mean "decide collectively to declare" -- sorry if that w

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On 20 March 2014 13:55, Hans de Goede wrote: > Hi, > > On 03/20/2014 07:45 PM, Lennart Poettering wrote: > > On Thu, 20.03.14 14:31, Martin Langhoff (martin.langh...@gmail.com) > wrote: > > > >> On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering < > mzerq...@0pointer.de>wrote: > >> > >>> I wonde

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thursday 20 March 2014 19:45:32 Lennart Poettering wrote: > No. systemd is not a firewall. It currently supports libwrap checks for > socket activated services. And I'd really like to get rid of that... Confession: I've never bothered looking in tcpwrappers code/api, so I'll take your assessme

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/20/2014 01:55 PM, Hans de Goede wrote: > Hi, > > On 03/20/2014 07:45 PM, Lennart Poettering wrote: >> On Thu, 20.03.14 14:31, Martin Langhoff >> (martin.langh...@gmail.com) wrote: >> >>> On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering >>> w

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Mar 20, 2014, at 1:39 PM, Adam Williamson wrote: > Sigh, for the fourth time, I'm not suggesting it. It's not my idea. I'm > not going to defend it. I'm relaying a design that was outlined to me by > the anaconda devs. The motivation is that there have been multiple > requests to make it poss

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

Hi, On 03/20/2014 07:45 PM, Lennart Poettering wrote: > On Thu, 20.03.14 14:31, Martin Langhoff (martin.langh...@gmail.com) wrote: > >> On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering >> wrote: >> >>> I wonder whether it wouldn't be time to say goodbye to tcpwrappers in >>> Fedora. There has

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, Mar 20, 2014 at 08:06:26PM +0100, Florian Weimer wrote: > I believe DenyHosts is unmaintained as well: fail2ban is maintained, does basically the same thing, can use iptables and optionally firewalld, and can watch the systemd journal. Maybe that could go in the release notes. I think in

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On 20 March 2014 13:05, Lennart Poettering wrote: > On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote: > > > > I doubt there are many people even using them anymore, firewalls are > > > more comprehensive and a lot more powerful, and while every admin knows > > > firewalls, I

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, 2014-03-20 at 20:20 +0100, Lennart Poettering wrote: > On Wed, 19.03.14 18:51, Adam Williamson (awill...@redhat.com) wrote: > > > > More complex than trying to mirror a FAT ESP partition across multiple > > > boot disks, keeping it properly synchronized, because RAID isn't > > > supported?

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

* Lennart Poettering: >> From my POV, it is kind of neat that you can grant access to *.enyo.de >> and deny every thing else. > > Binding access control to DNS sounds insecure like hell.. Additional restrictions are fine, for this purpose: >> This is quite helpful against scanners and worms,

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Wed, 19.03.14 18:51, Adam Williamson (awill...@redhat.com) wrote: > > More complex than trying to mirror a FAT ESP partition across multiple > > boot disks, keeping it properly synchronized, because RAID isn't > > supported? > > You can in theory just have a bunch of RAID-1 (mirrored) ESPs, be

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 20:06, Florian Weimer (f...@deneb.enyo.de) wrote: > * Stephen John Smoogen: > > > Actually they are used quite a bit in various service worlds. Mainly for > > ssh and email for dealing with scanners. [DenyHosts is a boon in this > > area.] > > I believe DenyHosts is unmaintained

Re: fail2ban + firewalld suggestions needed

On Thu, Mar 20, 2014 at 12:17:46PM -0400, Przemek Klosowski wrote: > >>>fail2ban-server - core components with minimal deps > >>>fail2ban-firewalld - firewalld support/configuration - requires firewalld > >>>fail2ban-hostsdeny - tcp_wrappers hosts.deny support - requires > >>>tcp_wrappers > >>>fai

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

* Stephen John Smoogen: > Actually they are used quite a bit in various service worlds. Mainly for > ssh and email for dealing with scanners. [DenyHosts is a boon in this > area.] I believe DenyHosts is unmaintained as well: > At the enter

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote: > > I doubt there are many people even using them anymore, firewalls are > > more comprehensive and a lot more powerful, and while every admin knows > > firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever >

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 14:31, Martin Langhoff (martin.langh...@gmail.com) wrote: > On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering > wrote: > > > I wonder whether it wouldn't be time to say goodbye to tcpwrappers in > > Fedora. There has been a request in systemd upstream to disable support > > >

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20.03.14 13:59, Paul Wouters (p...@nohats.ca) wrote: > Those who depend on it though, should see some "failed closed" > behaviour, so their service does not suddenly become more exposed. Well, this sounds like something to cover in the release notes, plus a check in fedup or so that tells

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering wrote: > I wonder whether it wouldn't be time to say goodbye to tcpwrappers in > Fedora. There has been a request in systemd upstream to disable support > As Stephen points out, they are used. Does systemd+xinetd match their functionality? chee

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On 20 March 2014 11:34, Lennart Poettering wrote: > Heya! > > I wonder whether it wouldn't be time to say goodbye to tcpwrappers in > Fedora. There has been a request in systemd upstream to disable support > for it by default, but I am not sure I want to do that unless we can > maybe say goodbye

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/20/2014 11:59 AM, Paul Wouters wrote: > On Thu, 20 Mar 2014, Lennart Poettering wrote: > >> I wonder whether it wouldn't be time to say goodbye to >> tcpwrappers in Fedora. > > I'd be happy to see those go. > > Those who depend on it though, s

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

On Thu, 20 Mar 2014, Lennart Poettering wrote: I wonder whether it wouldn't be time to say goodbye to tcpwrappers in Fedora. I'd be happy to see those go. Those who depend on it though, should see some "failed closed" behaviour, so their service does not suddenly become more exposed. Paul --

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Mar 20, 2014, at 10:32 AM, Przemek Klosowski wrote: > It is a darn useful side effect. How else can you implement redundant boot > that is transparently updated? For /boot, rather than /boot/efi, use metadata v1.2 and a bootloader that understands v1.2 metadata. GRUB2 has for some time.

EPEL and SCL

Hi, RHSCL 1.0 is GA since September. RHSCL 1.1 Beta is released today: http://developerblog.redhat.com/2014/03/20/rhscl-1-1-beta-available-apache-mongodb/ As EPEL is the common repository to find additional packages for RHEL, I really think it should also be possible to provide additional packag

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, 2014-03-20 at 10:07 -0700, Andrew Lutomirski wrote: > On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson wrote: > > On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote: > > > >> Adam's scheme is the only possibility. > > > >> Adam's raid1 /boot just seems more > >> reliable, especial

Maybe it's time to get rid of tcpwrappers/tcpd?

Heya! I wonder whether it wouldn't be time to say goodbye to tcpwrappers in Fedora. There has been a request in systemd upstream to disable support for it by default, but I am not sure I want to do that unless we can maybe say goodbye to it for the big picture too. Why would we get rid of them?

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, Mar 20, 2014 at 10:07 AM, Andrew Lutomirski wrote: > On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson wrote: >> Sure, UEFI has the capability, but it's not going to be used when simply >> booting the system normally. All the firmware does in that case is mount >> the partition and execut

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Mar 20, 2014, at 10:56 AM, Adam Williamson wrote: > On Wed, 2014-03-19 at 23:21 -0600, Chris Murphy wrote: > >> Therefore I don't think software RAID is a solution. > > Well, this is new: I'm fairly sure you were the one who filed a bug > requesting it in the first damn place. Where? I'm f

Re: Yet another bug caused by SELinux

On Thu, 2014-03-20 at 12:22 +0100, Kevin Kofler wrote: > Hi, > > GHC (Haskell) was broken for (at least) over a year because of a bug in the > workaround for stupid SELinux restrictions: > https://ghc.haskell.org/trac/ghc/ticket/7629 > https://bugzilla.redhat.com/show_bug.cgi?id=907515 > > How m

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson wrote: > On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote: > >> Adam's scheme is the only possibility. > >> Adam's raid1 /boot just seems more >> reliable, especially if it became a designed feature. > > It's not my plan, it's the anacond

Re: Yet another bug caused by SELinux

On Thu, 2014-03-20 at 12:35 +0100, H. Guémar wrote: > 2014-03-20 12:22 GMT+01:00 Kevin Kofler : > > Hi, > > > > GHC (Haskell) was broken for (at least) over a year because of a bug in the > > workaround for stupid SELinux restrictions: > > https://ghc.haskell.org/trac/ghc/ticket/7629 > > https://bu

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, 2014-03-20 at 09:49 -0700, Andrew Lutomirski wrote: > Um. > > EFI_FILE_PROTOCOL's Write method sounds suspiciously like it writes to > a filesystem. Sure, UEFI has the capability, but it's not going to be used when simply booting the system normally. All the firmware does in that case is

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Wed, 2014-03-19 at 23:21 -0600, Chris Murphy wrote: > Therefore I don't think software RAID is a solution. Well, this is new: I'm fairly sure you were the one who filed a bug requesting it in the first damn place. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedor

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote: > Adam's scheme is the only possibility. > Adam's raid1 /boot just seems more > reliable, especially if it became a designed feature. It's not my plan, it's the anaconda developers'. I only described it. Actually it took them like 15 m

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On Thu, Mar 20, 2014 at 9:32 AM, Przemek Klosowski wrote: > On 03/20/2014 01:21 AM, Chris Murphy wrote: >> You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because >> of how RAID-1 works; each individual member can also be mounted as if it >> was just a plain old partition, which is

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

On 03/20/2014 01:21 AM, Chris Murphy wrote: On Mar 19, 2014, at 7:51 PM, Adam Williamson wrote: On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote: More complex than trying to mirror a FAT ESP partition across multiple boot disks, keeping it properly synchronized, because RAID isn't s

Re: fail2ban + firewalld suggestions needed

On 20 March 2014 16:17, Przemek Klosowski wrote: > I am concerned that this looks like configuring the fail2ban package by > installing more packages. If we started doing it everywhere multiple > packages interact, it would combinatorially explode the number of packages > and make the system hard

Re: fail2ban + firewalld suggestions needed

On 03/20/2014 12:24 AM, Orion Poplawski wrote: On 03/19/2014 02:56 PM, Matthew Miller wrote: On Wed, Mar 19, 2014 at 02:32:40PM -0600, Orion Poplawski wrote: Hmm, I like this alternative a lot. I'm probably taking this too far, but I'm thinking of: fail2ban-server - core components with minim

Re: Strange ssh / openldap linking problem

Well this bug has reappeared on my machine. openldap depends on openldap-devel. $ ll /usr/lib64/libldap* lrwxrwxrwx. 1 root root 10 Feb 25 22:59 /usr/lib64/libldap-2.4.so.2 -> libldap.so -rwxr-xr-x. 1 root root 340608 Feb 4 09:08 /usr/lib64/libldap-2.4.so.2.10.2 lrwxrwxrwx. 1 root root

Re: fail2ban + firewalld suggestions needed

On 20 March 2014 13:04, Richard Shaw wrote: > On Wed, Mar 19, 2014 at 10:57 PM, Orion Poplawski > wrote: >> >> On 03/19/2014 09:10 PM, Richard Shaw wrote: >> > Ok using Jonathan's suggestion for the settings from a clean install I'm >> > getting an error whether I use the systemd backend or not..

Re: fail2ban + firewalld suggestions needed

On Wed, Mar 19, 2014 at 10:57 PM, Orion Poplawski wrote: > On 03/19/2014 09:10 PM, Richard Shaw wrote: > > Ok using Jonathan's suggestion for the settings from a clean install I'm > > getting an error whether I use the systemd backend or not... > > > >[12698]: ERROR ipset > > create fail2ban-ssh

[Bug 1052192] perl-IO-Socket-IP-0.25 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1052192 Petr Šabata changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version|

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

- Original Message - > Workstation might implement easy installation of alternative desktops in > the GNOME Software app at some point. Urgh. This is just moving the problem from the installer/media selection to the software installer. Just what would we gain by doing that given that there

Re: Yet another bug caused by SELinux

2014-03-20 12:22 GMT+01:00 Kevin Kofler : > Hi, > > GHC (Haskell) was broken for (at least) over a year because of a bug in the > workaround for stupid SELinux restrictions: > https://ghc.haskell.org/trac/ghc/ticket/7629 > https://bugzilla.redhat.com/show_bug.cgi?id=907515 > > How much breakage wil

Re: GCJ [was: pdftk retired?]

On 03/19/2014 10:59 PM, Andrew Hughes wrote: > - Original Message - >> On 03/08/2014 03:37 AM, Orcan Ogetbil wrote: >>> On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote: > > Sorry I am missing something. Why can't we keep the old pdftk that > works with itext2? Ch

Yet another bug caused by SELinux

Hi, GHC (Haskell) was broken for (at least) over a year because of a bug in the workaround for stupid SELinux restrictions: https://ghc.haskell.org/trac/ghc/ticket/7629 https://bugzilla.redhat.com/show_bug.cgi?id=907515 How much breakage will we have to suffer until people finally realize that