fail2ban
by Jeffrey Ross
I'm trying to configure fail2ban and it appears as if it is correctly
identifying addresses to ban however it doesn't appear to be successful
in banning hosts:
2017-09-24 16:01:46,073 fail2ban.actions [3591]: NOTICE [sshd]
Ban 91.210.178.96
2017-09-24 16:01:46,494 fail2ban.action [3591]: ERROR ipset add
fail2ban-sshd 91.210.178.96 timeout 31536000 -exist -- stdout: b''
2017-09-24 16:01:46,494 fail2ban.action [3591]: ERROR ipset add
fail2ban-sshd 91.210.178.96 timeout 31536000 -exist -- stderr: b'ipset
v6.29: The set with the given name does not exist\n'
2017-09-24 16:01:46,495 fail2ban.action [3591]: ERROR ipset add
fail2ban-sshd 91.210.178.96 timeout 31536000 -exist -- returned 1
2017-09-24 16:01:46,495 fail2ban.actions [3591]: ERROR Failed to
execute ban jail 'sshd' action 'firewallcmd-ipset' info
'CallingMap({'ip': '91.210.178.96', 'failures': 25, 'time':
1506283306.0737438, 'matches':
'2017-09-24T12:50:33.918187xyzzy.bubble.org sshd[31335]: Invalid user
admin from 91.210.178.96 port
51448\n2017-09-24T12:50:35.229995xyzzy.bubble.org sshd[31337]: Invalid
user admin from 91.210.178.96 port
51456\n2017-09-24T12:50:36.520259xyzzy.bubble.org sshd[31339]: Invalid
user admin from 91.210.178.96 port
51461\n2017-09-24T12:50:37.869954xyzzy.bubble.org sshd[31343]:
{removed part of the very long line showing all the matches in fail2 ban}
91.210.178.96 port 51705', 'ipmatches': <function
Actions.__checkBan.<locals>.<lambda> at 0x7f3ed78c7950>,
'ipjailmatches': <function Actions.__checkBan.<locals>.<lambda> at
0x7f3ed78c7c80>, 'ipfailures': <function
Actions.__checkBan.<locals>.<lambda> at 0x7f3ed78c7d90>,
'ipjailfailures': <function Actions.__checkBan.<locals>.<lambda> at
0x7f3ed78c7d08>})': Error banning 91.210.178.96
2017-09-24 16:01:46,909 fail2ban.actions [3591]: NOTICE [sshd]
91.210.178.96 already banned
2017-09-24 16:01:47,911 fail2ban.actions [3591]: NOTICE [sshd]
91.210.178.96 already banned
This is Fedora 26
/etc/fail2ban/fail2ban.conf is set to distribution default
/etc/fail2ban/jail.conf is set to distribution default
I've added in to fail2ban.d/local.conf
[fail2ban]
enabled = true
filter = fail2ban
action = iptables-allports[name=fail2ban]
logpath = /var/log/fail2ban.log
# findtime: 1 day
findtime = 86400
# bantime: 1 year
bantime = 31536000
maxretry = 5
to jail.d/00-firewalld.conf
[DEFAULT]
banaction = firewallcmd-ipset
sender = fail2ban(a)example.com
destemail = root
action = %(action_mwl)s
to jaild/10-sshd.conf
[sshd]
enabled=true
# findtime: 1 day
findtime = 86400
# bantime: 1 year
bantime = 31536000
and yes the system is currently setup to accept only public/private key
authentication for SSH, I'm assuming that once I get ssh figured out I
can get the other services figured out.
Thanks, Jeff
6 years, 6 months
Tomcat - different users for different instances?
by Peter Boy
When Fedora used systemV init you could define a specific user for a specific tomcat instance in /etc/systconfig/tomcat-[myinstance] by adding a line TOMCAT_USER=„mytomcat“.
In Fedora 26 with systemd you can define different Tomcat instances but the above mechanism doesn’t work anymore. I checked the starter script and couldn’t identify a way to define an instance specific user.
Well, does anybody know how I can achieve this?
My issue is: If my instances are all executing as the same user I get sometimes an „Too many open files“ error message and the instance stops executing. In RHEL it helps to define separate users per instance. The other instances were not affected by the broken one.
Thanks
Peter
6 years, 6 months
Installing pandoc-crossref on Fedora 26 using Cabal
by Ankur Sinha
Hello,
I've been trying to install `pandoc-crossref` on my Fedora 26 system
using Cabal, but can't seem to do so. I've tried three different
machines and get the same error on all. Would someone with some Haskell
experience be able to help please?
Here's the error. I've also filed the upstream but they haven't been
able to help either. It may be a Fedora specific issue?
https://github.com/lierdakil/pandoc-crossref/issues/132
> [asinha@ankur ~]$ cabal install pandoc-crossref
> Resolving dependencies...
> Configuring pandoc-crossref-0.2.6.0...
> Building pandoc-crossref-0.2.6.0...
> Failed to install pandoc-crossref-0.2.6.0
> Build log ( /home/asinha/.cabal/logs/pandoc-crossref-0.2.6.0.log ):
> cabal: Entering directory '/tmp/cabal-tmp-25488/pandoc-crossref-0.2.6.0'
> Configuring pandoc-crossref-0.2.6.0...
> Building pandoc-crossref-0.2.6.0...
> Preprocessing library pandoc-crossref-0.2.6.0...
> [ 1 of 18] Compiling Text.Pandoc.CrossRef.Util.PandocOrphans ( lib/Text/Pandoc/CrossRef/Util/PandocOrphans.hs, dist/build/Text/Pandoc/CrossRef/Util/PandocOrphans.o )
> [ 2 of 18] Compiling Text.Pandoc.CrossRef.Util.Gap ( lib/Text/Pandoc/CrossRef/Util/Gap.hs, dist/build/Text/Pandoc/CrossRef/Util/Gap.o )
> [ 3 of 18] Compiling Text.Pandoc.CrossRef.References.Types ( lib/Text/Pandoc/CrossRef/References/Types.hs, dist/build/Text/Pandoc/CrossRef/References/Types.o )
> [ 4 of 18] Compiling Text.Pandoc.CrossRef.Util.Util ( lib/Text/Pandoc/CrossRef/Util/Util.hs, dist/build/Text/Pandoc/CrossRef/Util/Util.o )
> [ 5 of 18] Compiling Text.Pandoc.CrossRef.Util.Meta ( lib/Text/Pandoc/CrossRef/Util/Meta.hs, dist/build/Text/Pandoc/CrossRef/Util/Meta.o )
> [ 6 of 18] Compiling Text.Pandoc.CrossRef.Util.CustomLabels ( lib/Text/Pandoc/CrossRef/Util/CustomLabels.hs, dist/build/Text/Pandoc/CrossRef/Util/CustomLabels.o )
> [ 7 of 18] Compiling Text.Pandoc.CrossRef.Util.Template ( lib/Text/Pandoc/CrossRef/Util/Template.hs, dist/build/Text/Pandoc/CrossRef/Util/Template.o )
> [ 8 of 18] Compiling Text.Pandoc.CrossRef.Util.Options ( lib/Text/Pandoc/CrossRef/Util/Options.hs, dist/build/Text/Pandoc/CrossRef/Util/Options.o )
> [ 9 of 18] Compiling Text.Pandoc.CrossRef.Util.CodeBlockCaptions ( lib/Text/Pandoc/CrossRef/Util/CodeBlockCaptions.hs, dist/build/Text/Pandoc/CrossRef/Util/CodeBlockCaptions.o )
> [10 of 18] Compiling Text.Pandoc.CrossRef.Util.Settings.Template ( lib/Text/Pandoc/CrossRef/Util/Settings/Template.hs, dist/build/Text/Pandoc/CrossRef/Util/Settings/Template.o )
> [11 of 18] Compiling Text.Pandoc.CrossRef.Util.Settings.Gen ( lib/Text/Pandoc/CrossRef/Util/Settings/Gen.hs, dist/build/Text/Pandoc/CrossRef/Util/Settings/Gen.o )
>
> lib/Text/Pandoc/CrossRef/Util/Settings/Gen.hs:30:16: error:
> • Pattern match failure in do expression at lib/Text/Pandoc/CrossRef/Util/Settings/Template.hs:52:5-15
> • In the untyped splice: $(makeCon ''Options 'Options)
> cabal: Leaving directory '/tmp/cabal-tmp-25488/pandoc-crossref-0.2.6.0'
> cabal: Error: some packages failed to install:
> pandoc-crossref-0.2.6.0 failed during the building phase. The exception was:
> ExitFailure 1
--
Thanks,
Regards,
Ankur Sinha "FranciscoD"
http://fedoraproject.org/wiki/User:Ankursinha
6 years, 6 months
Networkmanager openvpn and IPv6 address
by Ed Greshko
Has anyone tried making an openvpn connection with the gateway specified as an IPv6
address?
It makes no difference if I give the IPv6 address as it, enclose it with the standard
[ ] characters, or with quotes, the connection will fail immediately. If I give it a
DNS entry which contains only an AAAA record it will work.
Also, if I call openvpn directly with an IPv6 address in the config file it will also
work.
I think it is a bug in NetworkManager or I'm missing the magic incantation to specify
the address in a way NM would be happy.
--
Fedora Users List - The place to go to speculate endlessly
6 years, 6 months
Openvpn start fails on reboot
by Stephen Davies
If I reboot my F24 system, openvpn server fails to properly start but a
subsequent manual systemctl start openvpn@server does succeed.
The reboot log shows:
Mar 5 11:52:51 mustang audit: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=openvpn@server comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 5 11:52:51 mustang systemd: Started OpenVPN Robust And Highly Flexible
Tunneling Application On server.
Mar 5 11:52:51 mustang audit: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=openvpn@server comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 5 11:52:53 mustang systemd: openvpn(a)server.service: Main process exited,
code=exited, status=1/FAILURE
Mar 5 11:52:53 mustang systemd: openvpn(a)server.service: Unit entered failed
state.
Mar 5 11:52:53 mustang audit: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=openvpn@server comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Mar 5 11:52:53 mustang systemd: openvpn(a)server.service: Failed with result
'exit-code'.
It looks as if the automatic start may be happening too early in the boot process.
6 years, 6 months
Help frub to detect the righ OS
by Patrick Dupre
Hello,
I cannot remember, but there is a simple way to say to grub2-mkconfig
to find other /root
Right now, it find the right /boot,
but it miss the roots
For example, it find in my grub.cfg
root=/dev/mapper/VolGrpSys_DK1-root
while it should have seen:
/dev/mapper/VolGrpSys_DK3-root
Thank for your help.
===========================================================================
Patrick DUPRÉ | | email: pdupre(a)gmx.com
Laboratoire de Physico-Chimie de l'Atmosphère | |
Université du Littoral-Côte d'Opale | |
Tel. (33)-(0)3 28 23 76 12 | | Fax: 03 28 65 82 44
189A, avenue Maurice Schumann | | 59140 Dunkerque, France
===========================================================================
6 years, 6 months
Fwd: [openFATE 322297] Yast2 working in wayland
by ChunYu Wang
Seems SuSE will start to support wayland with YaST :-)
Really a good news.
- ChunYu
---------- Forwarded message ----------
From: <fate_noreply(a)suse.de>
Date: Thu, Sep 21, 2017 at 1:09 AM
Subject: [openFATE 322297] Yast2 working in wayland
To: opensuse-features(a)opensuse.org
Feature changed by: Keith Hizal (kah0922)
Feature #322297, revision 25
Title: Yast2 working in wayland
openSUSE Distribution: New
Priority
Requester: Important
Requested by: Andreas Winter (netzheimer)
Requested by: Frederic Crozat (fcrozat)
Requested by: Kai Dupke (kdupke)
Partner organization: openSUSE.org
Description:
Wayland is coming with big steps. First distributions (eg fedora)
already use it as default. Gnome should be already stable with it,
Plasmas support is getting better and better. Some other DE already
support it out of the box. Wayland is a lot more secure than Xserver
and it is the future. I think it is time to bring Yast2's support for
this. At the moment a user who wants to run wayland has just 2
solutions:
- Running yast in textmode (which is not a solution for non-geek users)
- Switch to another distribution, which offers better support
There were already some bugs opened by opensuse users. So you see the
feature is already needed.
https://bugzilla.opensuse.org/show_bug.cgi?id=955101
Discussion:
#1: Dominique Leuenberger (dimstar_suse) (2017-02-18 01:04:12)
Just repeating here the workaround from the bug (so you have a VERY
good workaround between your two options provided): xhost +LOCAL:
This entire issue is not limited to YaST - but in fact ANY GUI
application running as a different user (most likely root)
#2: Frederic Crozat (fcrozat) (2017-02-20 16:50:39Z) (reply to #1)
However, there is an interesting question here: why isn't YaST able to
start in Wayland mode directly, since it is using Qt5. It should be
able to run natively in Wayland and not requires X11..
#3: Frederic Crozat (fcrozat) (2017-02-21 13:55:20Z) (reply to #1)
A "slightly" more secure way:
xhost +SI:localuser:root
This is equivalent to the current security model used currently on
SLE12 / Leap.
#4: Frederic Crozat (fcrozat) (2017-02-21 14:11:37Z)
yast2 control center (Qt) or yast2 modules can be started in Wayland
after installing libqt5-wayland and setting "QT_QPA_PLATFORM=wayland".
But you need to be a regular user
+ #10: Keith Hizal (kah0922) (2017-09-20 17:09:30)
+ In the end xhost +SI:localuser:root is just a workaround and not a long
+ term solution. With Wayland not budging on running GUI apps as root, it
+ probably will be necessary run yast as a normal user and ask for the
+ root password once changes are made (possibly using polkit).
--
openSUSE Feature:
https://features.opensuse.org/322297
6 years, 6 months
Problem with SELinux: cannot change password, cannot open Plasma session
by Frédéric Bron
Hi,
I created a new user using kuser.
I wanted to change his password with passwd user :
$ su
$ passwd user
I got the following error:
passwd: Erreur de manipulation du jeton d'authentification
Then I did:
$ setenforce 0
and it worked.
Later, I reenabled selinux:
$ setenfoce 1
and the user tried to login with sddm to Plasma -> got a black screen
then back to sddm.
removed selinux:
$ setenforce 0
Login to Plasma worked
What's wrong with SELinux?
Frédéric
6 years, 6 months
DNF packages?
by Jeffrey Ross
How can I obtain a list of all packages currently installed on the system?
Thanks, Jeff
6 years, 6 months