MacOS X Mac Mail with SL Thunderbird issues

[Yasha Karant]

From a colleague:

Your mail client doesn’t play nicely with mine (Mac Mail).
As you can see by the screen snap, it doesn’t wrap text and includes the 
long version of headers on forwarded messages.
As a result, I sometimes don’t read stuff from you because it’s too 
annoying to scroll and scroll…


End quote.

A web search does not reveal anything about this issue.  I do not have 
an Apple MacOS X box; all Linux and MS Win Thunderbird users do not 
report this issue. I am using IMAP for reading email, and an external 
SMTP server for sending email.  Is there a (SL) Thunderbird 
configuration that is more Mac Mail friendly?


Yasha Karant

Re: Installing KDE on SL 6.8

[Karel Lang AFD]

Hi Larry,

i use KDE 4 on my SL 6.x for years, with no problem. The SL comes with 
basic Gnome 3 by default. But be ready for transition from KDE 3 -> KDE 4.


If you want to use KDE 4, then you need to install it specifically.

on my laptop:
yum grouplist | grep -i desktop
   Desktop
   Desktop Debugging and Performance Tools
   Desktop Platform
   General Purpose Desktop
   KDE Desktop
   Remote Desktop Clients
   Ice Desktop Environment
   Desktop Platform Development

so eg:
yum groupinstall "KDE Desktop"

br,
Karel


On 11/10/2016 09:48 PM, Larry Linder wrote:

Apoligize for bad Subject.
I am being forced for security reasons to migrate to 6.8 from 5.10.

I use KDE a have 12 desktops set up so I can run a number of cad
packages and numerous text adn spread sheets.

When I loaded 6.8 on to test hard ware I can't run KDE or switch to KDE.

I searced on web and found a lot of noise.

Any help would be appreciated.

Gnome just is not up the work load.  You speen all your time mousing
around.  I have 12 desktops running with several cad packages, circuit
designs, simulations, spice, Appachie OpenOffice, all running on
different desktops.  I need to switch between subjects quickly.

Thank You
Larry Linder
MicroControls LLC



--
*Karel Lang*
*Unix/Linux Administration*
l...@afd.cz | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz

Installing KDE on SL 6.8

[Larry Linder]

Apoligize for bad Subject.
I am being forced for security reasons to migrate to 6.8 from 5.10.

I use KDE a have 12 desktops set up so I can run a number of cad
packages and numerous text adn spread sheets.
 
When I loaded 6.8 on to test hard ware I can't run KDE or switch to KDE.
 
I searced on web and found a lot of noise.
 
Any help would be appreciated.
 
Gnome just is not up the work load.  You speen all your time mousing
around.  I have 12 desktops running with several cad packages, circuit
designs, simulations, spice, Appachie OpenOffice, all running on
different desktops.  I need to switch between subjects quickly.
 
Thank You
Larry Linder
MicroControls LLC

Installing KDE on windows 6.8

[Larry Linder]

I am being forced for security reasons to migrate to 6.8 from 5.10.

I use KDE a have 12 desktops set up so I can run a number of cad
packages and numerous text adn spread sheets.

When I loaded 6.8 on to test hard ware I can't run KDE or switch to KDE.

I searced on web and found a lot of noise.

Any help would be appreciated.

Gnome just is not up the work load.  You speen all your time mousing
around.  I have 12 desktops running with several cad packages, circuit
desings, simulations, spice, Appachie OpenOffice, running all at the
same time.  I need to switch between subjects quickly.

Thank You
Larry Linder
MicroControls LLC

Re: firewalld help

[Ken Teh]

Ok.  I see the problem now.  Default routes have always been a bit of a mystery 
to me.  Based on your reply, I manually deleted the default route for enp3s0 to 
confirm it works.  Then, I edited the connection with nmcli to remove the 
default permanently across reboots.

For everyone's benefit, the property setting is ipv4.never-default in nmcli.



On 11/10/2016 09:02 AM, Stephan Wiesand wrote:



On 10 Nov 2016, at 15:41, Ken Teh  wrote:

Default routes on the failing system.


[root@saudade ~]# ip --details route
unicast default via 192.168.203.1 dev enp3s0  proto static  scope global  
metric 100
unicast default via 146.139.198.1 dev enp4s0  proto static  scope global  
metric 101
unicast 146.139.198.0/23 dev enp4s0  proto kernel  scope link  src 
146.139.198.23  metric 100
unicast 192.168.203.0/24 dev enp3s0  proto kernel  scope link  src 
192.168.203.39  metric 100


This suggests tat saudade will send the response packages through enp3s0, unless the 
request originates from "the same subnet" (146.139.198.0/23). Is that expected 
to work?

You could check this with tcpdump.


On 11/10/2016 08:27 AM, Stephan Wiesand wrote:



On 10 Nov 2016, at 15:09, Ken Teh  wrote:

I'm trying to isolate a network problem and I need some debugging help.  
Frustrating when I am not fluent in the new sys admin tools.

Symptom is as follows:  I have a machine running Fedora 24 with its firewall 
zone set to work.  I cannot ping the machine except from the same subnet.  I 
don't have this problem with a second machine running the same OS/rev with the 
same firewall setup.  I'm not sure where to look.

I've dumped out both machines iptables.  See attachment.  I did a diff -y and they look 
almost identical.  The machine that does not work has 2 nics, one which is connected to a 
192.168 network.  It has additional rules in the various chains but they are all 
"from anywhere to anywhere".  I'm assuming the additional rules come from the 
second interface.

I've put a query to my networking folks to see if the problem is further 
upstream.  But I thought I'd ask if I have missed something obvious.


What's the default route on the "failing" system?


I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.

Re: firewalld help

[Stephan Wiesand]

> On 10 Nov 2016, at 15:41, Ken Teh  wrote:
> 
> Default routes on the failing system.
> 
>> [root@saudade ~]# ip --details route
>> unicast default via 192.168.203.1 dev enp3s0  proto static  scope global  
>> metric 100
>> unicast default via 146.139.198.1 dev enp4s0  proto static  scope global  
>> metric 101
>> unicast 146.139.198.0/23 dev enp4s0  proto kernel  scope link  src 
>> 146.139.198.23  metric 100
>> unicast 192.168.203.0/24 dev enp3s0  proto kernel  scope link  src 
>> 192.168.203.39  metric 100

This suggests tat saudade will send the response packages through enp3s0, 
unless the request originates from "the same subnet" (146.139.198.0/23). Is 
that expected to work?

You could check this with tcpdump.

> On 11/10/2016 08:27 AM, Stephan Wiesand wrote:
>> 
>>> On 10 Nov 2016, at 15:09, Ken Teh  wrote:
>>> 
>>> I'm trying to isolate a network problem and I need some debugging help.  
>>> Frustrating when I am not fluent in the new sys admin tools.
>>> 
>>> Symptom is as follows:  I have a machine running Fedora 24 with its 
>>> firewall zone set to work.  I cannot ping the machine except from the same 
>>> subnet.  I don't have this problem with a second machine running the same 
>>> OS/rev with the same firewall setup.  I'm not sure where to look.
>>> 
>>> I've dumped out both machines iptables.  See attachment.  I did a diff -y 
>>> and they look almost identical.  The machine that does not work has 2 nics, 
>>> one which is connected to a 192.168 network.  It has additional rules in 
>>> the various chains but they are all "from anywhere to anywhere".  I'm 
>>> assuming the additional rules come from the second interface.
>>> 
>>> I've put a query to my networking folks to see if the problem is further 
>>> upstream.  But I thought I'd ask if I have missed something obvious.
>> 
>> What's the default route on the "failing" system?
>> 
>>> I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.
>>> 
>>> 
>> 

Re: firewalld help

[Ken Teh]

Default routes on the failing system.


[root@saudade ~]# ip --details route
unicast default via 192.168.203.1 dev enp3s0  proto static  scope global  
metric 100
unicast default via 146.139.198.1 dev enp4s0  proto static  scope global  
metric 101
unicast 146.139.198.0/23 dev enp4s0  proto kernel  scope link  src 
146.139.198.23  metric 100
unicast 192.168.203.0/24 dev enp3s0  proto kernel  scope link  src 
192.168.203.39  metric 100



On 11/10/2016 08:27 AM, Stephan Wiesand wrote:



On 10 Nov 2016, at 15:09, Ken Teh  wrote:

I'm trying to isolate a network problem and I need some debugging help.  
Frustrating when I am not fluent in the new sys admin tools.

Symptom is as follows:  I have a machine running Fedora 24 with its firewall 
zone set to work.  I cannot ping the machine except from the same subnet.  I 
don't have this problem with a second machine running the same OS/rev with the 
same firewall setup.  I'm not sure where to look.

I've dumped out both machines iptables.  See attachment.  I did a diff -y and they look 
almost identical.  The machine that does not work has 2 nics, one which is connected to a 
192.168 network.  It has additional rules in the various chains but they are all 
"from anywhere to anywhere".  I'm assuming the additional rules come from the 
second interface.

I've put a query to my networking folks to see if the problem is further 
upstream.  But I thought I'd ask if I have missed something obvious.


What's the default route on the "failing" system?


I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.

Re: firewalld help

[Sebastian Luna Valero]

Hi Ken,

I have been recently learning about firewalld. Please run the commands
below on your hosts to see whether they look the same or not.

I hope it helps.

Best regards,
Sebastian

* General:

firewall-cmd --state

# Sometimes you need to reload the firewall to get the configuration
actually applied
firewall-cmd --reload

* Services:

firewall-cmd --get-services

firewall-cmd --permanent --get-services

firewall-cmd --info-service=smtp

​* Zones:

firewall-cmd --get-zones

firewall-cmd --get-default-zone

firewall-cmd --get-active-zones

firewall-cmd --get-zone-of-interface=em1

firewall-cmd --zone=work --list-interfaces

firewall-cmd --zone=work --list-all

firewall-cmd --zone=work --add-interface=em1

firewall-cmd --set-default-zone=internal

firewall-cmd --set-default-zone=public

firewall-cmd --get-default-zone

firewall-cmd --zone=work --list-rich-rules

firewall-cmd --permanent --zone=work --list-rich-rules

* Adding Ports

firewall-cmd --permanent --zone=work --add-port=80/tcp

# remember to:
firewall-cmd --reload

# check status:
firewall-cmd --zone=work --list-ports

* Removing Ports

firewall-cmd --zone=work --remove-port=80/tcp

* Adding Services

firewall-cmd --zone=work --add-service=ftp

* Removing Services

firewall-cmd --zone=work --remove-service=ftp

* Configure IP Address Masquerading

firewall-cmd --zone=external --query-masquerade

firewall-cmd --permanent --zone=external --add-masquerade

firewall-cmd --zone=external --remove-masquerade

Re: firewalld help

[Stephan Wiesand]

> On 10 Nov 2016, at 15:09, Ken Teh  wrote:
> 
> I'm trying to isolate a network problem and I need some debugging help.  
> Frustrating when I am not fluent in the new sys admin tools.
> 
> Symptom is as follows:  I have a machine running Fedora 24 with its firewall 
> zone set to work.  I cannot ping the machine except from the same subnet.  I 
> don't have this problem with a second machine running the same OS/rev with 
> the same firewall setup.  I'm not sure where to look.
> 
> I've dumped out both machines iptables.  See attachment.  I did a diff -y and 
> they look almost identical.  The machine that does not work has 2 nics, one 
> which is connected to a 192.168 network.  It has additional rules in the 
> various chains but they are all "from anywhere to anywhere".  I'm assuming 
> the additional rules come from the second interface.
> 
> I've put a query to my networking folks to see if the problem is further 
> upstream.  But I thought I'd ask if I have missed something obvious.

What's the default route on the "failing" system?

> I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.
> 
> 

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany

firewalld help

[Ken Teh]

I'm trying to isolate a network problem and I need some debugging help.  
Frustrating when I am not fluent in the new sys admin tools.

Symptom is as follows:  I have a machine running Fedora 24 with its firewall 
zone set to work.  I cannot ping the machine except from the same subnet.  I 
don't have this problem with a second machine running the same OS/rev with the 
same firewall setup.  I'm not sure where to look.

I've dumped out both machines iptables.  See attachment.  I did a diff -y and they look 
almost identical.  The machine that does not work has 2 nics, one which is connected to a 
192.168 network.  It has additional rules in the various chains but they are all 
"from anywhere to anywhere".  I'm assuming the additional rules come from the 
second interface.

I've put a query to my networking folks to see if the problem is further 
upstream.  But I thought I'd ask if I have missed something obvious.

I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.

Chain INPUT (policy ACCEPT)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere
INPUT_direct  all  --  anywhere anywhere
INPUT_ZONES_SOURCE  all  --  anywhere anywhere
INPUT_ZONES  all  --  anywhere anywhere
DROP   all  --  anywhere anywhere ctstate INVALID
REJECT all  --  anywhere anywhere reject-with 
icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere
FORWARD_direct  all  --  anywhere anywhere
FORWARD_IN_ZONES_SOURCE  all  --  anywhere anywhere
FORWARD_IN_ZONES  all  --  anywhere anywhere
FORWARD_OUT_ZONES_SOURCE  all  --  anywhere anywhere
FORWARD_OUT_ZONES  all  --  anywhere anywhere
DROP   all  --  anywhere anywhere ctstate INVALID
REJECT all  --  anywhere anywhere reject-with 
icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 
OUTPUT_direct  all  --  anywhere anywhere

Chain FORWARD_IN_ZONES (1 references)
target prot opt source   destination 
FWDI_work  all  --  anywhere anywhere[goto] 
FWDI_work  all  --  anywhere anywhere[goto] 
FWDI_work  all  --  anywhere anywhere[goto] 

Chain FORWARD_IN_ZONES_SOURCE (1 references)
target prot opt source   destination 

Chain FORWARD_OUT_ZONES (1 references)
target prot opt source   destination 
FWDO_work  all  --  anywhere anywhere[goto] 
FWDO_work  all  --  anywhere anywhere[goto] 
FWDO_work  all  --  anywhere anywhere[goto] 

Chain FORWARD_OUT_ZONES_SOURCE (1 references)
target prot opt source   destination 

Chain FORWARD_direct (1 references)
target prot opt source   destination 

Chain FWDI_work (3 references)
target prot opt source   destination 
FWDI_work_log  all  --  anywhere anywhere
FWDI_work_deny  all  --  anywhere anywhere
FWDI_work_allow  all  --  anywhere anywhere
ACCEPT icmp --  anywhere anywhere

Chain FWDI_work_allow (1 references)
target prot opt source   destination 

Chain FWDI_work_deny (1 references)
target prot opt source   destination 

Chain FWDI_work_log (1 references)
target prot opt source   destination 

Chain FWDO_work (3 references)
target prot opt source   destination 
FWDO_work_log  all  --  anywhere anywhere
FWDO_work_deny  all  --  anywhere anywhere
FWDO_work_allow  all  --  anywhere anywhere

Chain FWDO_work_allow (1 references)
target prot opt source   destination 

Chain FWDO_work_deny (1 references)
target prot opt source   destination 

Chain FWDO_work_log (1 references)
target prot opt source   destination 

Chain INPUT_ZONES (1 references)
target prot opt source   destination 
IN_workall  --  anywhere anywhere[goto] 
IN_workall  --  anywhere anywhere[goto] 
IN_workall  --  anywhere