Re: vncviewer

[Tom Rivers]

On 2/26/2014 16:25, Patrick Dupre wrote:

Can you telnet to the VNC port on the server?

How I do it?


I'm not sure telnet is the way to go because if memory serves it isn't 
installed by default.  The best way to check is to use a port scanner to 
see the status of the port on the target system.  The tool I use is 
called "nmap".  If you are using a Windows machine to vnc into the 
target system, you can download nmap from here:


http://nmap.org/download.html

If you are using Fedora to vnc to the target, then you can see if nmap 
is installed by running this as root from the command prompt:


yum info nmap

If it isn't installed, you can install it by using the following command:

yum install nmap

Once it is installed, you can run the following command on the source 
system to see if the target system has the port open:


nmap -v -n -P0 -p5900-5910 192.168.1.10

Just substitute the IP address of your target system for the address 
"192.168.1.10" in the example above.  A result of "closed" means the 
port is being actively blocked and a message is being sent to tell you 
that it is.  A result of "filtered" means that the port is not 
responding to say whether it is open or not.  Once a result of "open" 
means that you can access the service listening on the port.


I gave a range of 5900-5910 in the example above because you can 
configure the vnc service to listen on a number of different ports. That 
what the ":1" or ":2" mean when you set up the entries in the 
/etc/sysconfig/vncserver file.  This also means that to connect to a vnc 
server set up for ":2" on the example IP address above you need to use 
"192.168.1.10:2" in the vncviewer and the nmap output from probing the 
target system should show that port 5902 is open.


Let us know what you find.


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vncviewer

[Tom Rivers]

On 2/26/2014 16:49, Patrick Dupre wrote:

Starting Nmap 6.01 ( http://nmap.org ) at 2014-02-26 22:47 CET
Initiating SYN Stealth Scan at 22:47
Scanning 193.49.194.19 [4 ports]
Completed SYN Stealth Scan at 22:47, 3.01s elapsed (4 total ports)
Nmap scan report for 193.49.194.19
Host is up.
PORT STATESERVICE
5900/tcp filtered vnc
5901/tcp filtered vnc-1
5902/tcp filtered vnc-2
5903/tcp filtered vnc-3


This means that your firewall is blocking the ports or that your 
vncserver isn't really running on the target system.  You can determin 
if it is by running nmap on the target system and substituting 
"localhost" for the target IP like this:


nmap -v -n -P0 -p5900-5910 localhost

By the way, the IP address above appears to be public.  You may want to 
reconsider running a vncserver over the public Internet because the 
session is not encrypted.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vncviewer

[Tom Rivers]

On 2/26/2014 17:01, Patrick Dupre wrote:

# nmap -v -n -P0 -p5900-5910 localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2014-02-26 23:00 CET
Initiating SYN Stealth Scan at 23:00
Scanning localhost (127.0.0.1) [11 ports]
Discovered open port 5905/tcp on 127.0.0.1
Discovered open port 5906/tcp on 127.0.0.1
Discovered open port 5901/tcp on 127.0.0.1
Completed SYN Stealth Scan at 23:00, 0.01s elapsed (11 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.20s latency).
Other addresses for localhost (not scanned): 127.0.0.1
PORT STATE  SERVICE
5900/tcp closed vnc
5901/tcp open   vnc-1
5902/tcp closed vnc-2
5903/tcp closed vnc-3
5904/tcp closed unknown
5905/tcp open   unknown
5906/tcp open   unknown
5907/tcp closed unknown
5908/tcp closed unknown
5909/tcp closed unknown
5910/tcp closed cm


OK, the ports 5905 and 5906 are open and in use locally. Unfortunately, 
your previous scan results didn't show the status of those same ports 
from the remote machine.  Try the following command on the remote machine:


nmap -v -n -P0 -p5905-5906 193.49.194.19

If the ports aren't showing up as "open" then it is your firewall that 
is the problem.  Make sure you open those ports for both inbound and 
outbound traffic in your firewall configuration on the system running 
the vncserver.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vncviewer

[Tom Rivers]

On 2/26/2014 17:13, Patrick Dupre wrote:
How i do it? vncserver is not helpfull, Is it a file that I need to edit? 


It depends on how you configure your firewall settings.  I manage mine 
using a script that builds the iptables entries I need.  There are also 
other products that can perform the same function using a graphical 
interface.


You say SSH is working properly which is a good thing.  Here's something 
you can try.  From a root command prompt execute the following command:


iptables -L

What that will do is list all of your firewall settings.  Since SSH 
works, you should be able to find all of the lines that reference it in 
this output.  Make note of each of the chains it is listed under.  For 
each chain listing SSH, you should also see an entry for the two 
vncserver ports.  I suspect you are missing one or more entries and 
that's why it isn't working.


--
Tom Rivers
241 Rawlinson Road
Rochester, NY 14617
(585)342-8413 Home
(585)208-3178 Cell

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vncviewer

[Tom Rivers]

On 2/26/2014 18:57, Ed Greshko wrote:
FYI, it is the telnet server that is not installed by default. The 
client is 


Thanks Ed!


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vncviewer

[Tom Rivers]

On 2/27/2014 14:06, Jon Ingason wrote:

2014-02-27 19:03, Patrick Dupre skrev:

Hello,

For me
iptables -F

does not display anything!

That is because option -F means flushing the iptable, deleting all
rules. You should use option -L as Tom suggested.


While the rules are gone, you can try connecting with vnc.  That will 
certainly establish whether the firewall on that system is the problem.  
Just don't leave it off for very long.  ;)


To reset everything and get the firewall working again, you can issue 
the following command as root:


service iptables restart

Let us know what you find.


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vncviewer

[Tom Rivers]

On 2/27/2014 14:47, Patrick Dupre wrote:

iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination




It looks like your firewall is completely off.  Until you restart it, 
the output will not be very helpful.




Thu Feb 27 20:43:33 2014
  vncext:  VNC extension running!
  vncext:  Listening for VNC connections on all interface(s), port 5901
  vncext:  created VNC server for screen 0


Notice port 5901 is specified, previously you has only ports 5905 and 
5906 open.  It looks like you have made some modifications to your 
server setup...




gnome-session[22534]: CRITICAL: unable to create file 
'/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
gnome-session[22534]: CRITICAL: unable to create file 
'/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.


You may want to have a look at the following bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=956306



In my opinion I should probably change the rights on /run/user/1000/dconf/user 
!!!


Before you do that, look at the following comment in the bug report I 
referenced previously:


https://bugzilla.redhat.com/show_bug.cgi?id=956306#c6


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vncviewer

[Tom Rivers]

On 2/27/2014 15:58, Ed Greshko wrote:

FWIW, if you have ssh working and you use VNC over an SSH Tunnel you do not 
need ports 590X or any other ports open!


Agreed.  I mentioned at the outset that encryption was not present in 
vanilla vnc but it is extremely desirable.  In fact, I would go so far 
as to say it should be mandatory.


The only reason it was not addressed was due to a desire to keep the 
problem set as uncomplicated as possible in order to determine what the 
firewall configuration problem was.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: vncviewer

[Tom Rivers]

On 2/27/2014 15:37, Patrick Dupre wrote:

OK, I restarted it:


If you look below, I have removed all the chains that didn't reference 
SSH.  Notice that the VNC ports you were trying to access are not listed 
in these chains.  That's why you aren't getting access to them remotely.


Now that we have solved that part of the problem, it's worth restating 
that encrypting your VNC sessions is a really good idea I would strongly 
recommend.  Tunneling via SSH is an option and so is creating a VPN 
tunnel between the server and your remote system.



Chain IN_dmz_allow (1 references)
target prot opt source   destination
ACCEPT tcp  --  anywhere anywhere tcp dpt:ssh 
ctstate NEW

Chain IN_external_allow (1 references)
target prot opt source   destination
ACCEPT tcp  --  anywhere anywhere tcp dpt:ssh 
ctstate NEW

Chain IN_home_allow (1 references)
target prot opt source   destination
ACCEPT tcp  --  anywhere anywhere tcp dpt:ssh 
ctstate NEW
ACCEPT udp  --  anywhere anywhere udp dpt:ipp 
ctstate NEW
ACCEPT udp  --  anywhere 224.0.0.251  udp dpt:mdns 
ctstate NEW
ACCEPT udp  --  anywhere anywhere udp 
dpt:netbios-ns ctstate NEW
ACCEPT udp  --  anywhere anywhere udp 
dpt:netbios-dgm ctstate NEW

Chain IN_internal_allow (1 references)
target prot opt source   destination
ACCEPT tcp  --  anywhere anywhere tcp dpt:ssh 
ctstate NEW
ACCEPT udp  --  anywhere anywhere udp dpt:ipp 
ctstate NEW
ACCEPT udp  --  anywhere 224.0.0.251  udp dpt:mdns 
ctstate NEW
ACCEPT udp  --  anywhere anywhere udp 
dpt:netbios-ns ctstate NEW
ACCEPT udp  --  anywhere anywhere udp 
dpt:netbios-dgm ctstate NEW

Chain IN_public_allow (1 references)
target prot opt source   destination
ACCEPT udp  --  anywhere anywhere udp dpt:ipp 
ctstate NEW
ACCEPT udp  --  anywhere 224.0.0.251  udp dpt:mdns 
ctstate NEW
ACCEPT tcp  --  anywhere anywhere tcp dpt:ipp 
ctstate NEW
ACCEPT udp  --  anywhere anywhere udp dpt:ipp 
ctstate NEW
ACCEPT tcp  --  anywhere anywhere tcp dpt:ssh 
ctstate NEW

Chain IN_work_allow (1 references)
target prot opt source   destination
ACCEPT tcp  --  anywhere anywhere tcp dpt:ssh 
ctstate NEW
ACCEPT udp  --  anywhere 224.0.0.251  udp dpt:mdns 
ctstate NEW
ACCEPT udp  --  anywhere anywhere udp dpt:ipp 
ctstate NEW


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F19: Is this an httpd attack attempt?

[Tom Rivers]

On 3/5/2014 09:41, Tim wrote:

Allegedly, on or about 05 March 2014, lee sent:

Could someone please explain why/how this may be considered as an
attack or at least as something bad?

Have a look at the log line that the original poster sent:

185.4.227.194 - - [03/Mar/2014:07:27:49 -0800] "GET 
http://24x7-allrequestsallowed.com/?PHPSESSID=1rmsxtj500143TRMUTP_ODZZWA HTTP/1.1" 200 5264 
"-" "-"

look above here, where the carats are at the end of these hyphens 
-^^^

That "200" means a successful result, rather than a failure.  In other
words, what they tried to do, they did.


I've been following this discussion and decided to do some digging 
myself because I run several web servers and security is important to 
me.  I want to share what I've found to hopefully help determine what is 
happening here and ensure all of us are adequately protected.  Since I 
have two Linux web servers at my disposal, I used one as the proxy host 
and one as the target host so I could examine the logs of both servers 
and see what really happened.


The first thing I needed to do is replicate the attempt.  After poking 
around a bit, I came across the following example that anyone can use to 
simulate this "attack":


curl -x proxyhostdomainname:80 http://targethostdomainname

Executing this command makes a request to the proxyhostdomainname server 
and asks it to fetch the page at the targethostdomainname server.  After 
executing this command, I got the following output in the apache server 
access log on the proxyhostdomainname server:


XXX.XXX.XXX.XXX - - [05/Mar/2014:09:29:31 -0600] "GET 
http://targethostdomainname HTTP/1.1" 200 199


The address XXX.XXX.XXX.XXX corresponds to the third Linux system I was 
using to simulate the attack.  I also noted that the HTML source of the 
default page hosted at proxyhostdomainname was displayed in my terminal 
screen as a result of the curl command.


Now that I had successfully simulated the attack signature in the log 
file of the proxy web server, I logged into the target web server and 
looked at its access log.  Thankfully I found no log of any activity 
from my XXX.XXX.XXX.XXX workstation IP.  Not wanting to leave any stone 
unturned, I did a "tail -f" on the log file of the target web server and 
performed the same test again.  I got the same results.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F19: Is this an httpd attack attempt?

[Tom Rivers]

On 3/5/2014 10:45, Tom Rivers wrote:
Now that I had successfully simulated the attack signature in the log 
file of the proxy web server, I logged into the target web server and 
looked at its access log.  Thankfully I found no log of any activity 
from my XXX.XXX.XXX.XXX workstation IP.  Not wanting to leave any 
stone unturned, I did a "tail -f" on the log file of the target web 
server and performed the same test again.  I got the same results.


Sorry, it's a busy day at work and I wasn't as clear as I should have 
been in this last paragraph.  What I should've said is that there were 
no entries in the log file of the target web server referencing the 
attempted "attack" for either the IP of my workstation or the IP of the 
proxy web server.


Sorry for the confusion.


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: After a power cut my machine cannot boot

[Tom Rivers]

On 9/9/2015 13:36, Paul Smith wrote:

I have already tried to get the libidn rpm from a repo, but
again I get the same error with wget ("/lib64/libidn.so.11: file too
short").



Have you tried downloading the file from another system and transferring 
it using a USB flash drive?  You may also be able to boot from a live 
DVD/USB flash drive version of F21 on the broken system and use its 
functioning OS to download the file and place it on the hard drive so 
you can manually repair the file in question when you boot up normally.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Firefox 44 removes privacy feature.

[Tom Rivers]

On 2/4/2016 9:36 AM, Bernardo Sulzbach wrote:

After (two?) mentions to Google search, I wonder if any you know of
any paid web search engines?


I don't know about search engines that cost money, but I do know of a 
free one that is privacy oriented and it works really well:


https://duckduckgo.com/about


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Is there something like denyhosts for sasl dictionary attacks?

[Tom Rivers]

On 2/4/2016 4:07 PM, ven...@billoblog.com wrote:


Is there something like denyhosts for sasl attacks?  I'm getting tired
of stuff like this:


Jan 31 04:52:38 hope saslauthd[1333]: do_auth : auth failure:
[user=abby] [service=smtp] [realm=billoblog.com] [mech=pam] [reason=PAM
auth error]



I use fail2ban and you can configure custom filters to snag log entries 
of note, create custom jails for banning the offender after X failures 
for X amount of time (or indefinitely), and you can even have it 
maintain a database of the IPs logged so the next time you boot it will 
ban all the IPs again which also has a lifespan setting for its entries 
(i.e. finite of infinite ban time).



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Postfix and PTR record issues

[Tom Rivers]

On 2/9/2016 8:14 AM, arnaud gaboury wrote:

When looking at my DNS provider (Hurricane Electric), I effectively
have no PTR record. I must set one but honestly, I am far from
understanding everything about PTR.


The only people who can set up a PTR record are those who work for your 
ISP.  You have to contact them and tell then to point your IP address to 
the domain that accepts incoming email.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Postfix and PTR record issues

[Tom Rivers]

On 2/9/2016 8:57 AM, arnaud gaboury wrote:


Well, looking at my DNS provider home page, I have an entry to add
PTR. Furthermore, from HE FAQ[0]:



Am I wrong to think I can do it with my DNS provider ?


I went through this same issue with my ISP and they said they had to be 
the ones to change it.  I also originally read about PTR records here:


http://aplawrence.com/Blog/B961.html

According to the link you provided, it appears your ISP actually lets 
you make the change yourself.  If that's the case, then you're all set.  :)



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Lan connection problem -

[Tom Rivers]

On 2/9/2016 3:46 PM, Bob Goodwin wrote:


I can work around the problem by having my router powered from a UPS 
and being careful not to reboot the router. Once the router reboots 
the various wireless devices I have, printer, video cameras, etc. need 
their ac power "recycled" to get them connected to the LAN again. Very 
inconvenient at this time of year since some of these devices are in 
another building ...


When this happens I can not ping those devices, normally I should be 
able to connect to the cameras with the browser and reboot them when 
some glitch occurs but now when I lose the LAN connection I have to 
visit them and pull the plug. The printer is near at hand and toggling 
the power switch gets it back on.


I would make note of the MAC addresses on each of the devices and check 
your router to see if those devices are connected via wireless link 
after it reboots.  Also, you may be able to check the DHCP log of the 
router to see if requests are being made for IP addresses by any of the 
devices. Sometimes is will have a table of devices that have secured IP 
addresses and list their associate MAC addresses.


If they are shown as connected via wireless and are also in the DHCP 
table, then try nmap and see what results you get.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Lan connection problem -

[Tom Rivers]

On 2/9/2016 6:01 PM, Bob Goodwin wrote:
Now to add to the confusion I just tried an F23 portable that doesn't 
get updated as often and it connects to the camera 192.168.1.52 that 
this box10 can't as shown above. I will try booting another computer 
to Fedora 22 and see if it still works as before ... I suspect that 
perhaps something may have changed in network manager?


If I understand what you're saying, the following conditions are true:

- router reboot makes router unable to connect to other devices on the 
LAN that connect to it via wireless

- reboot of devices restores connectivity to router
- devices have static IP addresses on LAN
- when devices are unable to communicate with router they can 
communicate with other devices on the network


A sticking point for me, assuming I am not missing something, is that 
other devices can communicate with each other over the wireless link 
provided by the router but the router can't see any of them. That is 
really strange.  I would recommend restarting the firewall service but 
the fact rebooting a device makes things work again seems to indicate 
the firewall isn't the problem.


The fact rebooting a device, an external entity, causes the router to be 
able to communicate with it again might indicate that reconnecting to 
the wireless access point is what kicks things back into gear.  I know 
that a reboot will do this by default (grasping at straws here), but 
have you tried disabling/enabling the wireless service on the router 
after it has fully rebooted to see if that has any effect?  Maybe the 
run level it is being started at has something to do with the problem.  
Also, it might be interesting to execute "arp -a" on the router both 
before and after it reboots to see what results you get.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Lan connection problem -

[Tom Rivers]

On 2/10/2016 12:35 PM, Bob Goodwin wrote:
Note: This morning's tests are using the original Linksys E3000 router 
and Tomato 1.28 which was in use when the problem first appeared. Just 
thought I needed to go back and reassure myself that the replacement 
Buffalo/OpenWRT router wasn't introducing new problems.


I was under the impression that your router was the Fedora 23 box - now 
this is making a little more sense.  I notice you're using custom 
firmware on those devices and it makes me wonder whether they might play 
a role in some way.


The next thing I would try would be to wire the Fedora system and one of 
your other devices to the router and see if a router reboot affects the 
connectivity between the system and the device.  This procedure 
simplifies the problem set by removing the wireless piece of the 
puzzle.  If rebooting the router affects connectivity between the two 
wired devices, then you might have a problem with the router's switch.  
To confirm this you can substitute a simple switch for the router, 
connect both the system and the device to it, check connectivity, reboot 
the switch and check connectivity again - rebooting the switch should 
have no effect and the systems should be able to interact with each 
other consistently.


If rebooting the router doesn't affect the connectivity of the wired 
system and another wired device, then the problem might be with the 
router's wireless capability and possibly with how the system and other 
devices interact with it.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Trying to open ports in firewalld

[Tom Rivers]

On 2/23/2016 9:00 AM, Richard Shaw wrote:
Let's try the simple stuff first... Is your default zone for your 
network connection also "internal"?


That's the first thing I thought of as well.  In case you aren't sure 
which zone is your active zone, Tim, just look at the bottom right of 
the "Firewall Configuration" window.  Mine says, "Default Zone: external 
Lockdown: disabled Panic Mode: disabled."  That means if I want to 
adjust the current settings, I need to edit the "external" zone.


If you put your firewall exceptions in a zone other than the active one, 
then that might be your problem.



Tom


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Port 21 Open

[Tom Rivers]

On 3/4/2016 4:40 PM, Richard Ibbotson wrote:
I'll have a look at firewall settings. As far as I know port 21 is 
blocked. Strange 


Most firewalls are configured to block _incoming_ traffic.  Not many 
default system configurations block _outbound_ traffic and I can't 
remember a time I ever loaded a version of Fedora whose default firewall 
configuration does.  The data you provided earlier shows you are using 
an unprivileged local port (60088) to connect to a remote IP address 
using a reserved port (21).  Unless you have specifically blocked all 
outbound traffic from your system to external FTP servers, this 
connection will not be blocked.


This is the same kind of situation that occurs every time you connect to 
a remote web server with a local web browser.  Your system uses an 
unprivileged port locally to connect to the remote IP address and port 
80 (or 443 if you're using SSL).  Note that the reverse is completely 
different.  Ports 80 and 443 are most certainly blocked by default with 
respect to remote systems trying to connect to your local web server.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: OT: port forwarding with ssh

[Tom Rivers]

On 3/23/2016 3:10 PM, Mike Wright wrote:

usage: ssh -L [bind_address:]port:host:hostport]

Here's what I'm trying:

sudo ssh -L lo.cal.ip.adx:0:rem.ote.ip.adx:110



I successfully use the following to tunnel VNC over SSH so I can 
securely connect to a remote server at a hosting facility using VNC:


ssh -f -L 25901:127.0.0.1:5901 user@remotehost sleep 10; vncviewer 
127.0.0.1:25901:1


If I had to adapt it to your example, I would try this:

ssh -f -L 0:127.0.0.1:110 user@remotehost sleep 10; command you need to use to get your email>


The "-f" makes ssh act in the background and the "sleep 10" gives the 
ssh tunnel 10 seconds to actually connect before it bails.  The next 
statement should execute whatever process you need to execute but note 
that you want to execute it against the local host's loopback address, 
not the remote system's address.  You actually target the remote 
system's IP address using the "user@remotehost" section.



Tom
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: clueless question! - sortof sms/text related

[Tom Rivers]

On 6/17/2016 10:02 AM, bruce wrote:

Here's my use case.

Master process sends out msgs to 5 people, 'hey, gret deal' 1st 100 
people get it for price X"


The 5 people then send the msgs to their friends, who in turn send to 
their friends, etc..


You can use email to send out text messages if you know the network each 
recipient is on:


http://www.howtogeek.com/howto/27051/use-email-to-send-text-messages-sms-to-mobile-phones-for-free/

When people reply, they will reply to the email address from which the 
original message was sent.  That means you could automate a program to 
process incoming email to that address and do whatever you want with the 
data.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: sed question

[Tom Rivers]

On 7/21/2016 8:26 AM, bruce wrote:

Hey Tudor, and others..

The test sed I posted works for doing a search/replace of the text 
inside the parens...


> foo('txt')
> foo("txt")

however.. if i wanted to craft a sed that uses the entire 
>>foo('txt')<< as the search.. then I run into the need to handle the 
parens.. and that's the issue..


this doesn't work

sed -i 's/foo('txt')/foo('/dir1/txt') /' *files.dat
sed -i 's/foo\('txt'\)/foo\('/dir1/txt'\)/' *files.dat


If you swap out the apostrophes with quotation marks it should work - 
Bash is what I think is getting in your way.  On Fedora 23 I have the 
following in a text file called test.txt:


The 'test' case for changing foo('txt') to foo("txt") without changing 
bar('txt') to bar("txt") example.


I used the following sed command:

 sed -e "s/foo('txt')/foo(\"txt\")/g" test.txt

This is the output:

The 'test' case for changing foo("txt") to foo("txt") without changing 
bar('txt') to bar("txt") example.




Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: safety

[Tom Rivers]

On 1/18/2017 12:24 PM, Rick Stevens wrote:

That's normal. The system (or shell) is echoing the input because the
program you expect to consume the input isn't running or hasn't
finished initializing yet. What do you expect the system to do? Not
echo anything unless explicitly told to?


Perhaps I'm missing something here, but the answer to this dilemma seems 
to be as simple as don't ask for a password until you are ready to 
ensure it is handled properly.  More to the point, if the place on the 
display where a password is supposed to be entered is not shown, then a 
user won't be tempted to enter it.  The fact a password field is 
displayed should mean that the system is ready to deal with it 
appropriately.  Otherwise we can potentially get a "cart before the 
horse" situation like this one.



Tom
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: safety

[Tom Rivers]

On 1/18/2017 1:25 PM, Rick Stevens wrote:

That's not what's happening here. The user is starting a program, then
immediately typing in the expected password before the program starts,
essentially making use of the type-ahead capability of the shell.
The program hasn't, well, "registered" its stdin yet so the data is
echoed to the screen as there's no where else for it to go. There is no
way for the shell to know it shouldn't echo the data. The only way I
can see for this to not happen is to disable type-ahead in the shell.


Sorry, I should have been more specific because I agree with what you 
just said - there's not a whole lot that can be done about that.  
However, my previous comments were directed at the situation the OP 
identified:


On 1/18/2017 9:51 AM, Patrick Dupre wrote:

Hello,

When you log from the graphics interface (gnome) and provide the
password, if the system is slow (long response time), then the
password can appear in clear !!!



With respect to Gnome, I would suspect that there is a way to ensure 
that the prompt for password is only displayed when the system is ready 
to handle it properly.



Tom
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Adobe not providing linux flash updates

[Tom Rivers]

On 2/3/2015 16:47, Steven Stern wrote:

CNN works with Chrome.


That's because Flash is baked into the browser itself: 
https://support.google.com/chrome/answer/108086?hl=en



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

F21 - NetworkManager "hotspot.txt" TLS Failure Message

[Tom Rivers]

Good morning!

Since shortly after 4PM EDT on May 5, 2015 I have been seeing the 
following message in my system logs every 5 minutes:


NetworkManager[768]:   Connectivity check for uri 
'https://fedoraproject.org/static/hotspot.txt' failed with 'Peer failed 
to perform TLS handshake'.


I know this relates to the "Captive Portal" feature, 
https://fedorahosted.org/fesco/ticket/1337, but what I don't understand 
is why the TLS handshake is failing. For example, wget works without 
issue to retrieve the file:


wget --secure-protocol=TLSv1 https://fedoraproject.org/static/hotspot.txt
wget --secure-protocol=TLSv1_1 https://fedoraproject.org/static/hotspot.txt
wget --secure-protocol=TLSv1_2 https://fedoraproject.org/static/hotspot.txt

Has anyone else seen this?


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: F21 - NetworkManager "hotspot.txt" TLS Failure Message

[Tom Rivers]

On 5/8/2015 09:24, Tom Rivers wrote:

Good morning!

Since shortly after 4PM EDT on May 5, 2015 I have been seeing the 
following message in my system logs every 5 minutes:


NetworkManager[768]:   Connectivity check for uri 
'https://fedoraproject.org/static/hotspot.txt' failed with 'Peer 
failed to perform TLS handshake'.


I know this relates to the "Captive Portal" feature, 
https://fedorahosted.org/fesco/ticket/1337, but what I don't 
understand is why the TLS handshake is failing. For example, wget 
works without issue to retrieve the file:


wget --secure-protocol=TLSv1 https://fedoraproject.org/static/hotspot.txt
wget --secure-protocol=TLSv1_1 
https://fedoraproject.org/static/hotspot.txt
wget --secure-protocol=TLSv1_2 
https://fedoraproject.org/static/hotspot.txt


Has anyone else seen this?


This is still happening.  Anyone else experiencing this?  Anyone? Bueller?


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: why do we use systemd?

[Tom Rivers]

On 7/9/2014 07:12, Rahul Sundaram wrote:
All major distributions at this point have switched to systemd or in 
the process of doing so which should tell you the value of it.


With respect, just because there is consensus among governing entities 
doesn't necessarily mean that the decision is good for everyone.  
Consensus != Fact.  History is replete with examples.


I've been following this discussion and it appears obvious to me that 
there are some serious issues both philosophical and practical with the 
adoption of systemd.  To dismiss these issues and assign worth to the 
adoption of systemd merely because, as you have said, "everyone else is 
doing it" sounds illogical and ill-advised.


My mom always said, "If everyone else is jumping off the bridge, would 
you follow?"



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: why do we use systemd?

[Tom Rivers]

On 7/9/2014 09:57, Rahul Sundaram wrote:
Sure but if you want to go against the consensus, you will have to do 
something more concrete.


That is precisely why I challenged your assertion that the value of 
systemd was because everyone was adopting it.  The reason you gave for 
dismissing all of the gripes about systemd was anything but concrete.


So far, there are parts of systemd including logind which simply does 
not have any alternative that is actually maintained.


This is more of the kind of concrete argument I have come to expect from 
you from my time on these lists.  So basically the world desperately 
needs what logind does and since there was no alternative, all the other 
negative aspects of systemd must be tolerated as a result.  I'm willing 
to accept such reasoning if this is the case.  No solution is ever 
perfect, to be sure.


I am more of a software developer than a system architecture person so I 
will freely admit to not understanding the nuances of the whole systemd 
adoption issue.  However, my experience over the years with programming 
and system design make me sensitive to non-substantive arguments for the 
adoption of something new for its own sake.


Thanks for the clarification, Rahul.


Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Can not reach some web sites

[Tom Rivers]

On 9/19/2014 09:13, A.J. Bonnema wrote:
I was indeed able to find the site through IPV4 IP address, but not 
through the name. So I disabled IPV6 using the command from Ed, and 
low and behold: there is it was, case solved.


Since we're on the subject of problems accessing certain sites, I found 
a tool a while back that was helpful that I'd like to pass along:


http://downforeveryoneorjustme.com/

This site, if you can get to it, will identify if it's just you or if 
the problem is shared by the rest of the Internet.



Tom

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: is it the future?

[Tom Rivers]

On 9/23/2014 18:37, Rahul Sundaram wrote:

Hi

On Tue, Sep 23, 2014 at 6:18 PM, Dave Ihnat wrote:


Let's decide that before we argue any more on the merits--or lack
thereof--of systemd itself.  If it's not going to change Redhat's
decision, then all we can meaningfully discuss here are discovered
issues and any resolutions of same with the current implementation of
systemd.


 Fedora has adopted systemd long ago and RHEL has followed that.  It 
is unlikely Red Hat is going to change that direction based on 
conspiracy theories and personal attacks.


I don't think anyone would expect Red Hat to change direction based on 
"conspiracy theories and personal attacks".  What Dave positied, quite 
eloquently I might add, is the notion that substantive discussion might 
influence Red Hat with respect to systemd.  Can you speak to that 
specific point, Rahul?



Tom
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: is it the future?

[Tom Rivers]

On 9/24/2014 10:30, Rahul Sundaram wrote:

 Matthew already answered that.


My apologies - I must have missed his reply.  I'll go back and see if I 
can find it.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Level of discourse: how we can be more effective (and, systemd)

[Tom Rivers]

On 9/24/2014 09:13, Matthew Miller wrote:

We actually have almost exactly this.

Take a look at ,
linked in the bottom of every message. It says:

   This list provides community assistance, encouragement, and advice for
   Fedora users. Topics outside of that are generally not appropriate for
   this list. Please keep in mind that there are many thousands of
   subscribers and do your best to remain on-topic and courteous.


I noticed the words "encouragement" and "advice" are mentioned there.



Discussion about the direction of the distribution is not explicitly called
out as banned, but as you can see, it's clearly not the purpose of this
list.


Encouraging people to voice their views on Fedora issues and giving 
people advice on how a particular piece of Fedora operates so they can 
avoid problems seem to be very much a part of what this list is about.  
I'm not trying to be argumentative - I very much agree with keeping all 
discussions civil and productive.  However, after reading that and the 
list guidelines I can see no reason why an adult discussion of something 
like the adoption of "systemd" is contrary to the purpose of the list.  
A proper discussion educates users and, in some respects, those who have 
voiced legitimate concerns regarding "systemd" in a reasonable way are 
doing just that.  For an example of how part of this discussion has been 
educational, I've heard many people say something to the effect "I wish 
I had been paying attention to this a while ago."  Identifying 
discussions of whether "package-X" is good/bad/whatever as "not the 
purpose of this list" doesn't make much sense if these discussions are 
encouraging and assisting users to make informed decisions, offering 
reasonable advice, and are civil in nature.


If that is not the case, then I would wager most agree those lines of 
discussion are clearly are out of bounds not only with respect to the 
Code of Conduct but also with respect to plain old common sense.




The fact, though, is that this list isn't a good place for that because — 
largely because the tone is so often negative — it's not a forum that 
decision-makers can actually follow and get good
feedback from.


As someone who has been writing software and providing technical support 
for more than 30 years, I too have seen my fair share of negative 
commentary.  Still, I would hope that those who are in positions that 
can affect the direction of Fedora would at least be told of the 
substantive points being raised here, if any exist, and not simply allow 
good arguments to die because nobody is interested in picking them up 
out of the muck, rinsing them off, and repackaging them in a way that 
they can reach those who can truly make a difference.


More to the point, I understand why a user list is not necessarily the 
place where decision makers go to get up to speed on any given issue.  
However, if I were someone who saw an important point being raised in a 
forum like this and had access to those who could make a difference, I 
would be sure to write an email to the effect of, "Hey, I just heard an 
interesting argument about .  The crux is concise description here>.  Do you think this is something we should 
discuss?"


I've had to do that many times in the past myself.  I'd get copied in on 
some nasty emails from users who had an issue with something and most of 
the time it was just that: people being nasty.  However, sometimes the 
complaint was regarding a legitimate concern even though the commentary 
was completely toxic.  Rather than let a legitimate issue go unresolved, 
I took the essence of it to my boss and others in authority and pitched 
it in a more reasonable way. Sometimes I was able to sway them and 
sometimes I was told to drop it.  The bottom line is that I didn't let 
some venomous end user get in the way of doing what was right for the 
project I was charged with handling.


To be clear, I'm not indicting anyone here who is interested in 
instituting a cease fire.  My purpose is to demonstrate that sometimes 
it is important to repackage a tainted concern rather than allowing it 
to be flushed down the drain during the clean-up effort.




Technical decisions, including the adoption of systemd and anything further
we do with it, are made by FESCo, the Fedora Engineering Steering Committee,
which is entirely elected by Fedora users and contributors. Roles on this
committee are open to any Fedora packager. If you think we're doing a bad
job, I encourage you to stand for election, or find and support someone who
represents your views.


Some of the people voicing concerns are not Fedora packagers, so they 
aren't eligible to join this committee.  Finding someone who is already 
on the committee that supports a particular viewpoint can also be 
problematic.  Are you saying that there is no way to raise an issue with 
them without being a packager or having a like-minded pa

Re: restarting mysql databases

[Tom Rivers]

On 10/6/2014 12:33, Robert Moskowitz wrote:

mysqladmin -u root password 'mypass'

failed with:

mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'


The form of the command should be something like this:

mysql -h localhost -u root -p

I wouldn't specify a password on the command line for security reasons.  
If you execute the command I posted above, you will be automatically 
prompted for the user's password.  Of course, if you just reset the 
database, the root user won't have a password so you should omit the 
"-p" argument.


Alternatively, you can always run /usr/bin/mysql_secure_installation and 
that will help secure your installation.  It will also help you set the 
root password.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Permanently mount a USB Hard Disk for Security purpose

[Tom Rivers]

On 10/21/2014 09:31, Angelo Moreschini wrote:

[root@zorro ~]# mount -t ntfs UUID=36CC878C70FF1EC2 /media/PRTZ-src_syn

But now I get an error that I can not understand:
ntfs-3g-mount: failed to access mountpoint /media/PRTZ-src_syn: No 
such file or directory

_
_
_look that the directory doesn't exist._.

but this is not true:
[root@zorro ~]# ls /media
PRTZ-src_sync  PRTZ-svn_backup



It looks like the error says one directory and the ls command shows another:

/media/PRTZ-src_syn
/media/PRTZ-src_sync

I think you meant to type the command like this:

mount -t ntfs UUID=36CC878C70FF1EC2 /media/PRTZ-src_sync


Tom
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: Port knocking script/server for fedora?

[Tom Rivers]

On 11/19/2014 07:38, Bruno Wolff III wrote:

On Wed, Nov 19, 2014 at 11:58:11 +,
 Patrick O'Callaghan  wrote:


If the main concern is ssh hacking, you might consider denyhosts (yum
install denyhosts). It's easy to set up and seems to be effective. The
logs make fascinating (and scary) reading.


openssh stopped supporting tcpwrappers/libwrap in version 6.7 (which 
isn't in Fedora yet), so this will stop working in the not too distant 
future unless the Fedora maintainer puts that feature back in.


I've found fail2ban to be the weapon of choice.  Not only will it block 
brute force attempts by bad guys for SSH, but you can also configure it 
to block attempts against other services.  For example, I use it to 
block attempts to send email through the server from addresses that may 
be forged.  It works like a charm, is easy to configure and use, and yum 
should give it to you in a snap.



Tom
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Re: fail2ban vs. logrotate

[Tom Rivers]

On 10/25/2011 4:12 PM, Mike Wohlgemuth wrote:
> On 10/25/2011 11:12 AM, Mikkel L. Ellertson wrote:
>> It looks like you would have to modify the syslog logrotate script
>> and add a second command in the postrotate section after it restarts
>> syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
> That was my first thought, but I don't see any way to get fail2ban to
> reopen the log file without also forgetting the current ban list.

For what it's worth, I have been using fail2ban and logrotate together 
in a vanilla configuration for some time now and have never experienced 
this problem.  Right now it is running without incident on RHEL 5.7 and 
F14.  Are you sure you didn't tweak something, either on purpose or by 
accident, when you configured things?  If you haven't, then perhaps 
something has changed and that is why it no longer works as expected.


Tom
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Installing R-3*gz

[Tom Rivers]

On 4/30/2013 3:31 PM, Richard Vickery wrote:

checking for IceConnectionNumber in -lICE... no
checking X11/Intrinsic.h usability... no
checking X11/Intrinsic.h presence... no
checking for X11/Intrinsic.h... no
configure: error: --with-x=yes (default) and X11 headers/libs are not 
available


Would my next "yum install" be IceConectionNumber?


It appears that the default configuration this package is using expects 
X Windows to be present (the "--with-x=yes (default)" gave it away) and 
you evidently don't have any of those required packages installed.


This might be a dumb question but why don't you just try this?: yum 
install R


Yum is designed to pick up dependencies and figure everything out for 
you automagically.  ;)


--
Tom Rivers

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

FIXED: Fedora 36 pypolicyd-spf-2.9.3-1 Breaks Postfix SPF

[Tom Rivers]

Good morning,

TL;DR

   If your Fedora 36 Postfix SPF configuration is broken due to the
   latest pypolicyd-spf update, install python3-authres and restart
   postfix to get it working again.


I noticed when I updated my system this past weekend that SPF was no 
longer working after receiving a bounce message from another email 
address I use:


   Nov 13 14:20:47 impact-crater postfix/smtpd[203195]: connect from
   m474.em.secureserver.net[198.71.246.105]
   Nov 13 14:20:48 impact-crater postfix/smtpd[203195]: Anonymous TLS
   connection established from
   m474.em.secureserver.net[198.71.246.105]: TLSv1.3 with cipher
   TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519
   server-signature RSA-PSS (2048 bits) server-digest SHA256
   Nov 13 14:20:48 impact-crater postfix/smtpd[203195]: warning:
   premature end-of-input on private/policyd-spf while reading input
   attribute name
   Nov 13 14:20:49 impact-crater postfix/smtpd[203195]: warning:
   premature end-of-input on private/policyd-spf while reading input
   attribute name
   Nov 13 14:20:49 impact-crater postfix/smtpd[203195]: warning:
   problem talking to server private/policyd-spf: Connection reset by peer
   Nov 13 14:20:49 impact-crater postfix/smtpd[203195]: NOQUEUE:
   reject: RCPT from m474.em.secureserver.net[198.71.246.105]: 451
   4.3.5 : Recipient address rejected: Server
   configuration problem;
   
from=
   to= proto=ESMTP helo=
   Nov 13 14:20:49 impact-crater postfix/smtpd[203195]: using
   backwards-compatible default setting
   smtpd_relay_before_recipient_restrictions=no to reject recipient
   "t...@impact-crater.com" from client
   "m474.em.secureserver.net[198.71.246.105]"
   Nov 13 14:20:49 impact-crater postfix/smtpd[203195]: disconnect from
   m474.em.secureserver.net[198.71.246.105] ehlo=2 starttls=1 mail=1
   rcpt=0/1 quit=1 commands=5/6

Running policyd-spf manually gave me the following output:

   [root@impact-crater ~]# /usr/libexec/postfix/policyd-spf
   Traceback (most recent call last):
  File "/usr/libexec/postfix/policyd-spf", line 33, in 
    sys.exit(load_entry_point('spf-engine==2.9.3',
   'console_scripts', 'policyd-spf')())
  File "/usr/libexec/postfix/policyd-spf", line 25, in
   importlib_load_entry_point
    return next(matches).load()
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line
   171, in load
    module = import_module(match.group('module'))
  File "/usr/lib64/python3.10/importlib/__init__.py", line 126, in
   import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 992, in
   _find_and_load_unlocked
  File "", line 241, in
   _call_with_frames_removed
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1006, in
   _find_and_load_unlocked
  File "", line 688, in _load_unlocked
  File "", line 883, in
   exec_module
  File "", line 241, in
   _call_with_frames_removed
  File "/usr/lib/python3.10/site-packages/spf_engine/__init__.py",
   line 54, in 
    import authres
   ModuleNotFoundError: No module named 'authres'

I discovered that installing python3-authres-1.2.0-12.fc36.noarch and 
restarting postfix seems to have fixed things:


   dnf install python3-authres
   postfix reload

I hope this helps anyone else who ran into this.


Tom
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 37 - Cockpit Software Update Display Questions

[Tom Rivers]

Good morning,

There are two things that I have noticed lately when performing upgrades 
using cockpit:


1) When viewing the update log in real time, the display no longer 
automatically scrolls to show new entries.


2) The "Verifying" line of text above the progress indicator seems to be 
missing information and instead displays "undefined" (see attached image)


Is this by design?


Tom

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

FIX - Fedora 40 RoundCube Internal Error 500

[Tom Rivers via users]

Hello!

For anyone running RoundCube on Fedora 40, it evidently now requires the 
following package to be installed:


php-endroid-qrcode

I upgraded from Fedora 39 a few days ago and found I could no longer 
access it - I just got a blank page.  By simply installing the 
aforementioned package it started working.


Tom
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fail2ban is failing

[Tom Rivers via users]

Until the fix is available, I've been able to get it running until the 
next system reboot by doing the following:


# setenforce 0
# systemctl start fail2ban

... wait a minute ...

# setenforce 1

Tom

On 5/3/2024 12:39 PM, Patrick O'Callaghan wrote:

On Fri, 2024-05-03 at 06:45 -0500, Richard Shaw wrote:

On Fri, May 3, 2024 at 6:31 AM Patrick O'Callaghan

wrote:


F40 fully updated.


Try a `dnf --refresh update`. The fix just went to stable last night.

That just gets the same update I already tried.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Service pmie_daily Failing Due To Incorrect File Ownership

[Tom Rivers via users]

Hello,

A few weeks ago, I believe shortly after the pcp package was updated in 
Fedora 38, the pmie_daily service would show as failed in cockpit.  I 
did some checking and found that at least one of the files was owned by 
root instead of pcp like below for the file pmie.log.20230604:


   -rw-r--r--. 1 pcp  pcp  108 Jun  4 19:33 pmie.log
   -rw-r--r--. 1 pcp  pcp  192 May 23 00:08 pmie.log.20230522.xz
   -rw-r--r--. 1 pcp  pcp  172 May 24 00:08 pmie.log.20230523.xz
   -rw-r--r--. 1 pcp  pcp  276 May 25 08:36 pmie.log.20230524.xz
   -rw-r--r--. 1 pcp  pcp  208 May 25 08:41 pmie.log.20230525.xz
   -rw-r--r--. 1 pcp  pcp  224 May 26 08:37 pmie.log.20230526.xz
   -rw-r--r--. 1 pcp  pcp  212 May 28 00:08 pmie.log.20230527.xz
   -rw-r--r--. 1 pcp  pcp  256 May 29 09:13 pmie.log.20230528.xz
   -rw-r--r--. 1 pcp  pcp  204 May 30 00:08 pmie.log.20230529.xz
   -rw-r--r--. 1 pcp  pcp  196 May 31 00:08 pmie.log.20230530.xz
   -rw-r--r--. 1 pcp  pcp  200 Jun  1 00:08 pmie.log.20230531.xz
   -rw-r--r--. 1 pcp  pcp  260 Jun  2 09:02 pmie.log.20230601.xz
   -rw-r--r--. 1 pcp  pcp  155 Jun  3 00:08 pmie.log.20230602
   -rw-r--r--. 1 pcp  pcp  358 Jun  4 19:26 pmie.log.20230603
   -rw-r--r--. 1 root root 193 Jun  4 19:33 pmie.log.20230604
   -rw-r--r--. 1 pcp  pcp  137 May 22 08:28 pmie.log.prior

If I change the ownership back to pcp and restart the service, 
everything works fine.  Does anyone know what might be causing this and 
what can be done to keep this from reoccurring?


Thanks!


Tom
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue