Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 12/10/18 2:10 PM, Rick Stevens wrote:
> On 12/10/18 1:01 PM, Stephen Morris wrote:
>> On 7/12/18 9:10 am, Ed Greshko wrote:
>>> On 12/7/18 4:33 AM, Stephen Morris wrote:
 Thanks Ed, I'll try that again.

 I am using a vpn called Slickvpn. I did download *.ovpn files for
 each location but I
 didn't issue the command you mentioned. I manually created the vpn
 definitions in
 network manager and manually populated the information in those
 definitions by manually
 reading the .ovpn files and transferring the information contained in
 them into the
 definitions, plus the "vendor" supplied a windows client that enabled
 selection of the
 site to connect to and supplied all the necessary configuration, that
 I also used to get
 the configuration for the networkmanager definitions. As it has been
 over 12 months
 since I last used them, which would have been in F27, what I don't
 know at this stage is
 whether things have changed with all their servers or whether F28
 changes are
 causing issues with this particular vpn.
>>> There is no need to "manually" add the connection in Network Manager. 
>>> Network Manager has
>>> an "import" function which will do things for you.  One thing it does
>>> is put the certs in
>>> the proper location.  This ensures that the selinux context is correct
>>> for them.
>>>
>> I've renamed my existing definitions to import the configuration, and in
>> doing the rename I noticed that the UDP port specified is now different
>> to the ports their windows client provides as selections. Their windows
>> client provides an auto setting for the port which keeps connecting and
>> disconnecting without ever providing a static connection. The port that
>> did work for one of the two sites I tried, being , was not the same
>> port in the linux definition that worked 12 months ago, being 443.
>>
>> I tried creating a vpn definition from Networkmanager in KDE by creating
>> the definition via the import function, but that doesn't work for my
>> situation at the moment. My OVPN files are on my windows partition, and
>> when I navigate to /mnt where the mount points are, the import dialog
>> shows me all the directories in /mnt except the three windows
>> directories even though those mount points are currently mounted. All
>> the directories in /mnt are owned by root and world readable. How do I
>> find out why the Networkmanager dialog won't show them?
> 
> In order to walk down a directory tree, the directories have to have
> execute privileges, not merely read privileges (e.g. "chmod -R w+x /mnt"
> should do it).

Or more selectively:

find /mnt -type d -exec chmod w+x '{}' \;

to give execute permission to JUST the directories under /mnt.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-Admitting you have a problem is the first step toward getting   -
-medicated for it.  -- Jim Evarts (http://www.TopFive.com)   -
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 12/10/18 1:01 PM, Stephen Morris wrote:
> On 7/12/18 9:10 am, Ed Greshko wrote:
>> On 12/7/18 4:33 AM, Stephen Morris wrote:
>>> Thanks Ed, I'll try that again.
>>>
>>> I am using a vpn called Slickvpn. I did download *.ovpn files for
>>> each location but I
>>> didn't issue the command you mentioned. I manually created the vpn
>>> definitions in
>>> network manager and manually populated the information in those
>>> definitions by manually
>>> reading the .ovpn files and transferring the information contained in
>>> them into the
>>> definitions, plus the "vendor" supplied a windows client that enabled
>>> selection of the
>>> site to connect to and supplied all the necessary configuration, that
>>> I also used to get
>>> the configuration for the networkmanager definitions. As it has been
>>> over 12 months
>>> since I last used them, which would have been in F27, what I don't
>>> know at this stage is
>>> whether things have changed with all their servers or whether F28
>>> changes are
>>> causing issues with this particular vpn.
>> There is no need to "manually" add the connection in Network Manager. 
>> Network Manager has
>> an "import" function which will do things for you.  One thing it does
>> is put the certs in
>> the proper location.  This ensures that the selinux context is correct
>> for them.
>>
> I've renamed my existing definitions to import the configuration, and in
> doing the rename I noticed that the UDP port specified is now different
> to the ports their windows client provides as selections. Their windows
> client provides an auto setting for the port which keeps connecting and
> disconnecting without ever providing a static connection. The port that
> did work for one of the two sites I tried, being , was not the same
> port in the linux definition that worked 12 months ago, being 443.
> 
> I tried creating a vpn definition from Networkmanager in KDE by creating
> the definition via the import function, but that doesn't work for my
> situation at the moment. My OVPN files are on my windows partition, and
> when I navigate to /mnt where the mount points are, the import dialog
> shows me all the directories in /mnt except the three windows
> directories even though those mount points are currently mounted. All
> the directories in /mnt are owned by root and world readable. How do I
> find out why the Networkmanager dialog won't show them?

In order to walk down a directory tree, the directories have to have
execute privileges, not merely read privileges (e.g. "chmod -R w+x /mnt"
should do it).
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-"You think that's tough?  Try herding cats!"-
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 12/11/18 5:01 AM, Stephen Morris wrote:
> How do I find out why the Networkmanager dialog won't show them?

I don't know.

Why don't you just go to the slickVPN site and download them from there?

-- 
Right: I dislike the default color scheme Wrong: What idiot picked the default 
color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 7/12/18 9:10 am, Ed Greshko wrote:

On 12/7/18 4:33 AM, Stephen Morris wrote:

Thanks Ed, I'll try that again.

I am using a vpn called Slickvpn. I did download *.ovpn files for each location 
but I
didn't issue the command you mentioned. I manually created the vpn definitions 
in
network manager and manually populated the information in those definitions by 
manually
reading the .ovpn files and transferring the information contained in them into 
the
definitions, plus the "vendor" supplied a windows client that enabled selection 
of the
site to connect to and supplied all the necessary configuration, that I also 
used to get
the configuration for the networkmanager definitions. As it has been over 12 
months
since I last used them, which would have been in F27, what I don't know at this 
stage is
whether things have changed with all their servers or whether F28 changes are
causing issues with this particular vpn.

There is no need to "manually" add the connection in Network Manager.  Network 
Manager has
an "import" function which will do things for you.  One thing it does is put 
the certs in
the proper location.  This ensures that the selinux context is correct for them.

I've renamed my existing definitions to import the configuration, and in 
doing the rename I noticed that the UDP port specified is now different 
to the ports their windows client provides as selections. Their windows 
client provides an auto setting for the port which keeps connecting and 
disconnecting without ever providing a static connection. The port that 
did work for one of the two sites I tried, being , was not the same 
port in the linux definition that worked 12 months ago, being 443.


I tried creating a vpn definition from Networkmanager in KDE by creating 
the definition via the import function, but that doesn't work for my 
situation at the moment. My OVPN files are on my windows partition, and 
when I navigate to /mnt where the mount points are, the import dialog 
shows me all the directories in /mnt except the three windows 
directories even though those mount points are currently mounted. All 
the directories in /mnt are owned by root and world readable. How do I 
find out why the Networkmanager dialog won't show them?



regards,

Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 12/7/18 4:33 AM, Stephen Morris wrote:
> Thanks Ed, I'll try that again.
>
> I am using a vpn called Slickvpn. I did download *.ovpn files for each 
> location but I
> didn't issue the command you mentioned. I manually created the vpn 
> definitions in
> network manager and manually populated the information in those definitions 
> by manually
> reading the .ovpn files and transferring the information contained in them 
> into the
> definitions, plus the "vendor" supplied a windows client that enabled 
> selection of the
> site to connect to and supplied all the necessary configuration, that I also 
> used to get
> the configuration for the networkmanager definitions. As it has been over 12 
> months
> since I last used them, which would have been in F27, what I don't know at 
> this stage is
> whether things have changed with all their servers or whether F28 changes are
> causing issues with this particular vpn. 

There is no need to "manually" add the connection in Network Manager.  Network 
Manager has
an "import" function which will do things for you.  One thing it does is put 
the certs in
the proper location.  This ensures that the selinux context is correct for them.


-- 
Right: I dislike the default color scheme Wrong: What idiot picked the default 
color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 5/12/18 11:18 pm, Ed Greshko wrote:

On 12/5/18 5:20 AM, Ed Greshko wrote:

On 12/5/18 4:41 AM, Stephen Morris wrote:

The vpn I'm using, which operates through Openvpn, has servers all over the 
world

Kindly tell us which VPN service you are using.


Oh, and I should have also added this

The service you're using most likely has you download an *.ovpn file for each 
location
they have servers.  Make sure you have the most recent version.  You said you 
haven't used
it in a while and they may have changed their keys or other parameters.

Then, to avoid having to search the logs, simply execute as root (or use sudo)

openvpn whatever.ovpn

It should, if your provider is "normal", prompt you for username and password.  
Then you
should have all the information you need about why the connection fails.


Thanks Ed, I'll try that again.

I am using a vpn called Slickvpn. I did download *.ovpn files for each 
location but I didn't issue the command you mentioned. I manually 
created the vpn definitions in network manager and manually populated 
the information in those definitions by manually reading the .ovpn files 
and transferring the information contained in them into the definitions, 
plus the "vendor" supplied a windows client that enabled selection of 
the site to connect to and supplied all the necessary configuration, 
that I also used to get the configuration for the networkmanager 
definitions. As it has been over 12 months since I last used them, which 
would have been in F27, what I don't know at this stage is whether 
things have changed with all their servers or whether F28 changes are 
causing issues with this particular vpn.



regards,

Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 12/5/18 5:20 AM, Ed Greshko wrote:
> On 12/5/18 4:41 AM, Stephen Morris wrote:
>> The vpn I'm using, which operates through Openvpn, has servers all over the 
>> world
> Kindly tell us which VPN service you are using.
>

Oh, and I should have also added this

The service you're using most likely has you download an *.ovpn file for each 
location
they have servers.  Make sure you have the most recent version.  You said you 
haven't used
it in a while and they may have changed their keys or other parameters.

Then, to avoid having to search the logs, simply execute as root (or use sudo)

openvpn whatever.ovpn

It should, if your provider is "normal", prompt you for username and password.  
Then you
should have all the information you need about why the connection fails.

-- 
Right: I dislike the default color scheme Wrong: What idiot picked the default 
color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 12/5/18 4:41 AM, Stephen Morris wrote:
> The vpn I'm using, which operates through Openvpn, has servers all over the 
> world

Kindly tell us which VPN service you are using.

-- 
Right: I dislike the default color scheme Wrong: What idiot picked the default 
color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 28/11/18 8:51 am, Rick Stevens wrote:

On 11/27/18 12:48 PM, Stephen Morris wrote:

On 27/11/18 10:53 am, Rick Stevens wrote:

On 11/26/18 1:46 PM, Stephen Morris wrote:

On 21/11/18 10:02 am, Rick Stevens wrote:

On 11/20/18 2:09 PM, Ed Greshko wrote:

On 11/21/18 5:07 AM, Stephen Morris wrote:



A second, smaller time jump will appear once chronyd actually syncs the
system clock to true UTC (indicated by that "stepped by" bit in the
logs). Once that happens, then log entries will be accurate from that
point onwards and chronyd will do its best to keep the system clock
synced to UTC. Keep in mind that journalctl will assume ALL log entries
have a UTC timestamp, regardless of when the clocks got mangled and this
is the cause of the time shifts in the display. The radical change in
system clock when it switches from local time to UTC time MAY cause
programs to malfunction, since they assume that the system clock was in
UTC. This _may_ be why your VPN was disconnecting...it assumed there was
no traffic for whatever the difference is between your local time and
UTC, so it disconnects.

I can understand the time sync causing a problem with the VPN, but the
question I have is why now? Its probably 12 months since the last time I
ran the VPN, so it would have been in F27 and earlier where the VPN was
actively being used and there were no issues with the bios clock being
set to local time, which is how I've been running the bios time settings
for over 30 years, except for once when I did try it set to GMT and
Windows couldn't handle it, but also having said that I haven't been
running Linux for that long, I've only been running it at home for 10 or
so years and I have always at least dual booted.

Could my issue be that this time shift issue has always been present but
its only now that it is becoming obvious?

It's possible. It's also possible that the VPN client (vpnc, whatever)
uses a different default timeout setting now. The old one worked OK, the
new one requires you override it in the config. It also may be that the
VPN server has been updated and doesn't like something. As I said, this
clock thing _may_ explain the VPN dropout. I just don't know.

The only way to know is if the reason generates log entries (and we hope
it does). In that case, you may need to look at ALL of the log entries.
If the dropout occurs somewhere near when the timestamps get funky,
that's a good indication that the clock changes are causing it. Just why
should be revealed in the log entries.

I'm just spitballing this. The cause may be totally unrelated. As
always, troubleshooting sporadic things of this nature remotely (even
locally) is difficult--especially when you can only look at one end of
the connection (VPN server logs, if available, would be useful).


I suspect the time shift isn't an issue, as I'm starting the vpn's from 
within KDE where I thought the time shift has already taken place, plus 
journalctl seems to be indicating that the time shift has taken place 
before chronyd has started.


The vpn I'm using, which operates through Openvpn, has servers all over 
the world, and you configure it for the one you want to use. I've tried 
the one closest to Australia that gives the best performance (being 
Singapore) and the one they recommend (being Miami) and they both behave 
the same way. The vpn is started, NetworkManager indicates the vpn is 
"active" (by placing a lock icon on top of the network icon in the 
system tray), it stays in that state for about 30 seconds according to 
journalctl and then it logs a terminate message, and it takes about a 
further 30 seconds for the vpn to actually shutdown.


I've changed a couple of parameters in the config, so I'll see whether 
they have any impact, but at the moment I'm using Linux fairly infrequently.



regards,

Steve




--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-   Sarchasm: The gulf between the author of sarcastic wit and the   -
- reader...who doesn't get it.   -
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: 

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/27/18 12:48 PM, Stephen Morris wrote:
> On 27/11/18 10:53 am, Rick Stevens wrote:
>> On 11/26/18 1:46 PM, Stephen Morris wrote:
>>> On 21/11/18 10:02 am, Rick Stevens wrote:
 On 11/20/18 2:09 PM, Ed Greshko wrote:
> On 11/21/18 5:07 AM, Stephen Morris wrote:


>> A second, smaller time jump will appear once chronyd actually syncs the
>> system clock to true UTC (indicated by that "stepped by" bit in the
>> logs). Once that happens, then log entries will be accurate from that
>> point onwards and chronyd will do its best to keep the system clock
>> synced to UTC. Keep in mind that journalctl will assume ALL log entries
>> have a UTC timestamp, regardless of when the clocks got mangled and this
>> is the cause of the time shifts in the display. The radical change in
>> system clock when it switches from local time to UTC time MAY cause
>> programs to malfunction, since they assume that the system clock was in
>> UTC. This _may_ be why your VPN was disconnecting...it assumed there was
>> no traffic for whatever the difference is between your local time and
>> UTC, so it disconnects.
> 
> I can understand the time sync causing a problem with the VPN, but the
> question I have is why now? Its probably 12 months since the last time I
> ran the VPN, so it would have been in F27 and earlier where the VPN was
> actively being used and there were no issues with the bios clock being
> set to local time, which is how I've been running the bios time settings
> for over 30 years, except for once when I did try it set to GMT and
> Windows couldn't handle it, but also having said that I haven't been
> running Linux for that long, I've only been running it at home for 10 or
> so years and I have always at least dual booted.
> 
> Could my issue be that this time shift issue has always been present but
> its only now that it is becoming obvious?

It's possible. It's also possible that the VPN client (vpnc, whatever)
uses a different default timeout setting now. The old one worked OK, the
new one requires you override it in the config. It also may be that the
VPN server has been updated and doesn't like something. As I said, this
clock thing _may_ explain the VPN dropout. I just don't know.

The only way to know is if the reason generates log entries (and we hope
it does). In that case, you may need to look at ALL of the log entries.
If the dropout occurs somewhere near when the timestamps get funky,
that's a good indication that the clock changes are causing it. Just why
should be revealed in the log entries.

I'm just spitballing this. The cause may be totally unrelated. As
always, troubleshooting sporadic things of this nature remotely (even
locally) is difficult--especially when you can only look at one end of
the connection (VPN server logs, if available, would be useful).


--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-   Sarchasm: The gulf between the author of sarcastic wit and the   -
- reader...who doesn't get it.   -
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 27/11/18 10:53 am, Rick Stevens wrote:

On 11/26/18 1:46 PM, Stephen Morris wrote:

On 21/11/18 10:02 am, Rick Stevens wrote:

On 11/20/18 2:09 PM, Ed Greshko wrote:

On 11/21/18 5:07 AM, Stephen Morris wrote:

Given that the front screen of the bios is displaying the time as
local time, presumably
that means that the time settings in the bios are local time and the
motherboard bios
doesn't provide any means to input the time as GMT, hence the bios
is not set to GMT.

Let me try this one last time.  And it will be one last time.  I can
tell you how to set
your system up to get consistent log entries.  It will be your choice
to do it or not.

You have already said that the motherboard has no concept of time
zones.  That is totally
irrelevant.  YOU know what time it is and YOU know what time zone you
are in!

I look at my mobile phone and see it is 05:55 on November 21.  I know
I am in GMT+8.  So,
GMT time is now 21:55 on November 20.  So, I go to my BIOS screen and
enter 21:55 as the
time and November 20 as the date.  The motherboard clock is NOW set
to GMT!  It matter not
one lick if the MB has an idea of any time zone!

Step one Done.


Thinking about the data as displayed by journalctl at boot time, the
time stamp on the
messages of Nov18 18:16 for a Nov 18 7am boot would make sense if
the OS assumed the
system clock was GMT and added the local zone offset to the time.

Given the fact that my /etc/adjtime has local as the last line, and
from my recollection
I have not explicitly run the indicated commands that would set
that, why is the OS not
honouring that specification right from boot commencement?

Set that last line to UTC.  You have now told the O/S that the HW
clock is set to
UTC/GMT.  So now the O/S knows what you know.

Step two Done.

Make sure the the link /etc/localtime points to a correct time zone
for where your system
is physically located.

[egreshko@meimei etc]$ ll /etc/localtime
lrwxrwxrwx. 1 root root 33 Dec 21  2017 /etc/localtime ->
../usr/share/zoneinfo/Asia/Taipei

for ME.

(you can use timedatectl to show/set)

Step three Done.

Reboot

Done.

You will now get correct and consistent date/time stamps in your logs
going forwad.
Previous timestamps won't be fixed.  Don't want to do that.  Well,
you'll be in the same
situation you are now and that will be that.



With the time zone data coming from the tzdata package, are you
saying that each year
when the local governments change when daylight saving starts and
ends, that the tzdata
package is updated to reflect that?

Look at the changelog for the package as I showed you.

rpm -q --changelog tzdata

and you will see the dates it was updated and why it was updated.
The answer to your
question is obvious.

And to make it clear, Linux expects the SYSTEM clock to be in UTC,
Windows expects it to be in local time. The SYSTEM clock is set to the
BIOS clock at boot time for both OSes. There is really no (clean) way to
make these two disparate things live together. There is a way to bugger
Windows to use a UTC clock via a registry entry, but it's a kludge.
Choose which one (Windows or Linux) is your primary OS, and set your
BIOS clock accordingly (localtime for Windows, UTC for Linux).

At the moment my main OS is Windows as I spend a fair amount of time
playing online games that can't be played under Linux, so I mainly only
boot to Linux for email processing, until such time as I decide to forgo
the gaming environment and get back into serious development work. I
haven't investigated recently the ability of VM's to provide the
necessary hardware graphics quality for gaming, but the last time I
looked at this possibility the graphics capabilities weren't up to scratch.

Given that /etc/localtime seems to be a symbolic link to
/usr/share/zoneinfo, for the same reasons that /etc may not be mounted
/usr may also not be mounted, so how does the boot system know what
offset to add to the bios time to reach local time?

At boot time (when the logging starts), the system uses the hardware
clock to set the system clock, so all logs will be based on what the
hardware clock was set to (and the assumption is that it's UTC). All
log entries are stamped with the system clock value. Later, once /etc
and /usr are mounted, the logger NOW knows what your local timezone is
and the log entries will be DISPLAYED in your local timezone. The log
entries themselves (in the database) still are being tagged with the
system clock value.

Later on, chronyd drags the system clock into sync with UTC and the log
entries from then on have the correct UTC timestamp. However, they are
still displayed in your local timezone. journalctl has no idea when the
timestamps changed, so log entries made before chronyd did its thing
will be displayed with the wrong timestamp.


Linux will handle a localtime BIOS clock better. If your BIOS clock is
in local time (as Windows wants) and you boot Linux, the log entries
will have the incorrect time until chronyd drags the SYSTEM 

Re: VPN Interface not Remaining Active With Firewall?

[Patrick O'Callaghan]

On Tue, 2018-11-27 at 08:46 +1100, Stephen Morris wrote:
> At the moment my main OS is Windows as I spend a fair amount of time 
> playing online games that can't be played under Linux, so I mainly only 
> boot to Linux for email processing, until such time as I decide to forgo 
> the gaming environment and get back into serious development work. I 
> haven't investigated recently the ability of VM's to provide the 
> necessary hardware graphics quality for gaming, but the last time I 
> looked at this possibility the graphics capabilities weren't up to scratch.

This is somewhat OT but with the right setup it is possible to run
Windows games (even AAA titles) under a VM with VFIO graphics pass-
through. I've been doing this for a couple of years now with quite a
bit of success. You need an extra GPU and your CPU, motherboard and
BIOS all have to support it, but it can be done.

Here's a Quora post I wrote about it:

https://www.quora.com/Is-it-possible-to-run-all-Windows-games-on-Fedora-Linux

There is also an interesting recent development from Steam, where
they're developing mods to Wine to support DirectX over Vulcan:

https://arstechnica.com/gaming/2018/08/valves-steam-play-uses-vulkan-to-bring-more-windows-games-to-linux/

I've yet to try it out but it looks positive.

Now back to our regularly-scheduled programming.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/26/18 1:46 PM, Stephen Morris wrote:
> On 21/11/18 10:02 am, Rick Stevens wrote:
>> On 11/20/18 2:09 PM, Ed Greshko wrote:
>>> On 11/21/18 5:07 AM, Stephen Morris wrote:

 Given that the front screen of the bios is displaying the time as
 local time, presumably
 that means that the time settings in the bios are local time and the
 motherboard bios
 doesn't provide any means to input the time as GMT, hence the bios
 is not set to GMT.
>>> Let me try this one last time.  And it will be one last time.  I can
>>> tell you how to set
>>> your system up to get consistent log entries.  It will be your choice
>>> to do it or not.
>>>
>>> You have already said that the motherboard has no concept of time
>>> zones.  That is totally
>>> irrelevant.  YOU know what time it is and YOU know what time zone you
>>> are in!
>>>
>>> I look at my mobile phone and see it is 05:55 on November 21.  I know
>>> I am in GMT+8.  So,
>>> GMT time is now 21:55 on November 20.  So, I go to my BIOS screen and
>>> enter 21:55 as the
>>> time and November 20 as the date.  The motherboard clock is NOW set
>>> to GMT!  It matter not
>>> one lick if the MB has an idea of any time zone!
>>>
>>> Step one Done.
>>>
 Thinking about the data as displayed by journalctl at boot time, the
 time stamp on the
 messages of Nov18 18:16 for a Nov 18 7am boot would make sense if
 the OS assumed the
 system clock was GMT and added the local zone offset to the time.

 Given the fact that my /etc/adjtime has local as the last line, and
 from my recollection
 I have not explicitly run the indicated commands that would set
 that, why is the OS not
 honouring that specification right from boot commencement?
>>> Set that last line to UTC.  You have now told the O/S that the HW
>>> clock is set to
>>> UTC/GMT.  So now the O/S knows what you know.
>>>
>>> Step two Done.
>>>
>>> Make sure the the link /etc/localtime points to a correct time zone
>>> for where your system
>>> is physically located.
>>>
>>> [egreshko@meimei etc]$ ll /etc/localtime
>>> lrwxrwxrwx. 1 root root 33 Dec 21  2017 /etc/localtime ->
>>> ../usr/share/zoneinfo/Asia/Taipei
>>>
>>> for ME.
>>>
>>> (you can use timedatectl to show/set)
>>>
>>> Step three Done.
>>>
>>> Reboot
>>>
>>> Done.
>>>
>>> You will now get correct and consistent date/time stamps in your logs
>>> going forwad.
>>> Previous timestamps won't be fixed.  Don't want to do that.  Well,
>>> you'll be in the same
>>> situation you are now and that will be that.
>>>
>>>
 With the time zone data coming from the tzdata package, are you
 saying that each year
 when the local governments change when daylight saving starts and
 ends, that the tzdata
 package is updated to reflect that?
>>> Look at the changelog for the package as I showed you.
>>>
>>> rpm -q --changelog tzdata
>>>
>>> and you will see the dates it was updated and why it was updated. 
>>> The answer to your
>>> question is obvious.
>> And to make it clear, Linux expects the SYSTEM clock to be in UTC,
>> Windows expects it to be in local time. The SYSTEM clock is set to the
>> BIOS clock at boot time for both OSes. There is really no (clean) way to
>> make these two disparate things live together. There is a way to bugger
>> Windows to use a UTC clock via a registry entry, but it's a kludge.
>> Choose which one (Windows or Linux) is your primary OS, and set your
>> BIOS clock accordingly (localtime for Windows, UTC for Linux).
> 
> At the moment my main OS is Windows as I spend a fair amount of time
> playing online games that can't be played under Linux, so I mainly only
> boot to Linux for email processing, until such time as I decide to forgo
> the gaming environment and get back into serious development work. I
> haven't investigated recently the ability of VM's to provide the
> necessary hardware graphics quality for gaming, but the last time I
> looked at this possibility the graphics capabilities weren't up to scratch.
> 
> Given that /etc/localtime seems to be a symbolic link to
> /usr/share/zoneinfo, for the same reasons that /etc may not be mounted
> /usr may also not be mounted, so how does the boot system know what
> offset to add to the bios time to reach local time?

At boot time (when the logging starts), the system uses the hardware
clock to set the system clock, so all logs will be based on what the
hardware clock was set to (and the assumption is that it's UTC). All
log entries are stamped with the system clock value. Later, once /etc
and /usr are mounted, the logger NOW knows what your local timezone is
and the log entries will be DISPLAYED in your local timezone. The log
entries themselves (in the database) still are being tagged with the
system clock value.

Later on, chronyd drags the system clock into sync with UTC and the log
entries from then on have the correct UTC timestamp. However, they are
still displayed in your local timezone. journalctl has no 

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/27/18 5:46 AM, Stephen Morris wrote:
> I haven't investigated recently the ability of VM's to provide the necessary 
> hardware
> graphics quality for gaming, but the last time I
> looked at this possibility the graphics capabilities weren't up to scratch.

That is correct.

If Windows is your main O/S to use then why don't you install VirtualBox on it
(https://www.virtualbox.org/) and run Fedora in a VM on Windows? 

-- 
Right: I dislike the default color scheme Wrong: What idiot picked the default 
color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 27/11/18 8:45 am, Lester M Petrie wrote:

On 11/26/2018 4:25 PM, Stephen Morris wrote:

On 21/11/18 9:09 am, Ed Greshko wrote:



question is obvious.


Having installed the motherboard over 12 months ago and not touched 
the time settings since, it wasn't until two days ago that I 
realised, through trial and error, that the bios date/time could be 
changed and how to do it (its changed by clicking on the time display 
in the bottom right hand corner), I was looking for options entries 
like other motherboards I've had. I can change this setting to GMT, 
but I also boot to Windows 10 and I am not sure I can trust Windows 
to honour the registry setting, plus I also boot to Ubuntu and I'm 
not sure how Ubuntu handles this at the moment.




I have been running Windows since Windows 7 with the hardware clock 
set to GMT.  In fact my problem has been that for the last 3-4 
installs of Fedora, the install has set the clock to be on local time 
and I have had to reset it to be GMT. I can't speak to how Ubuntu 
interfaces with the HW clock.


Thats interesting, I've had issues in the past with Windows 7 not being 
able to properly handle the bios clock being GMT so I set the clock to 
local time and I've never run it any other way since.



regards,

Steve






regards,

Steve




___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 21/11/18 10:02 am, Rick Stevens wrote:

On 11/20/18 2:09 PM, Ed Greshko wrote:

On 11/21/18 5:07 AM, Stephen Morris wrote:


Given that the front screen of the bios is displaying the time as local time, 
presumably
that means that the time settings in the bios are local time and the 
motherboard bios
doesn't provide any means to input the time as GMT, hence the bios is not set 
to GMT.

Let me try this one last time.  And it will be one last time.  I can tell you 
how to set
your system up to get consistent log entries.  It will be your choice to do it 
or not.

You have already said that the motherboard has no concept of time zones.  That 
is totally
irrelevant.  YOU know what time it is and YOU know what time zone you are in!

I look at my mobile phone and see it is 05:55 on November 21.  I know I am in 
GMT+8.  So,
GMT time is now 21:55 on November 20.  So, I go to my BIOS screen and enter 
21:55 as the
time and November 20 as the date.  The motherboard clock is NOW set to GMT!  It 
matter not
one lick if the MB has an idea of any time zone!

Step one Done.


Thinking about the data as displayed by journalctl at boot time, the time stamp 
on the
messages of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS 
assumed the
system clock was GMT and added the local zone offset to the time.

Given the fact that my /etc/adjtime has local as the last line, and from my 
recollection
I have not explicitly run the indicated commands that would set that, why is 
the OS not
honouring that specification right from boot commencement?

Set that last line to UTC.  You have now told the O/S that the HW clock is set 
to
UTC/GMT.  So now the O/S knows what you know.

Step two Done.

Make sure the the link /etc/localtime points to a correct time zone for where 
your system
is physically located.

[egreshko@meimei etc]$ ll /etc/localtime
lrwxrwxrwx. 1 root root 33 Dec 21  2017 /etc/localtime -> 
../usr/share/zoneinfo/Asia/Taipei

for ME.

(you can use timedatectl to show/set)

Step three Done.

Reboot

Done.

You will now get correct and consistent date/time stamps in your logs going 
forwad.
Previous timestamps won't be fixed.  Don't want to do that.  Well, you'll be in 
the same
situation you are now and that will be that.



With the time zone data coming from the tzdata package, are you saying that 
each year
when the local governments change when daylight saving starts and ends, that 
the tzdata
package is updated to reflect that?

Look at the changelog for the package as I showed you.

rpm -q --changelog tzdata

and you will see the dates it was updated and why it was updated.  The answer 
to your
question is obvious.

And to make it clear, Linux expects the SYSTEM clock to be in UTC,
Windows expects it to be in local time. The SYSTEM clock is set to the
BIOS clock at boot time for both OSes. There is really no (clean) way to
make these two disparate things live together. There is a way to bugger
Windows to use a UTC clock via a registry entry, but it's a kludge.
Choose which one (Windows or Linux) is your primary OS, and set your
BIOS clock accordingly (localtime for Windows, UTC for Linux).


At the moment my main OS is Windows as I spend a fair amount of time 
playing online games that can't be played under Linux, so I mainly only 
boot to Linux for email processing, until such time as I decide to forgo 
the gaming environment and get back into serious development work. I 
haven't investigated recently the ability of VM's to provide the 
necessary hardware graphics quality for gaming, but the last time I 
looked at this possibility the graphics capabilities weren't up to scratch.


Given that /etc/localtime seems to be a symbolic link to 
/usr/share/zoneinfo, for the same reasons that /etc may not be mounted 
/usr may also not be mounted, so how does the boot system know what 
offset to add to the bios time to reach local time?




Linux will handle a localtime BIOS clock better. If your BIOS clock is
in local time (as Windows wants) and you boot Linux, the log entries
will have the incorrect time until chronyd drags the SYSTEM clock into
sync with UTC. The log entries will be correct from that point onwards.

So, use journalctl to look for log entries for chronyd:

journalctl -b -u chronyd

And look for the lines that indicate the clock was reset:

  chronyd<[pid]>: System clock was
stepped by  seconds


I've issued the command above and the last message displayed says that 
the 'System clock TAI was stepped by 37 seconds', the first two messages 
displayed, both with the same timestamp were 'Starting NTP client 
server' and 'cronyd version 3.14 starting'. The thing that was 
interesting about all the messages displayed by the journalctl command 
was that the timestamp on all the messages was local time, which I 
assume means that the system clock was running in local time before 
cronyd was started?



regards,

Steve




Log entries before that assume your local time is UTC, will be 

Re: VPN Interface not Remaining Active With Firewall?

[Lester M Petrie]

On 11/26/2018 4:25 PM, Stephen Morris wrote:

On 21/11/18 9:09 am, Ed Greshko wrote:



question is obvious.


Having installed the motherboard over 12 months ago and not touched the 
time settings since, it wasn't until two days ago that I realised, 
through trial and error, that the bios date/time could be changed and 
how to do it (its changed by clicking on the time display in the bottom 
right hand corner), I was looking for options entries like other 
motherboards I've had. I can change this setting to GMT, but I also boot 
to Windows 10 and I am not sure I can trust Windows to honour the 
registry setting, plus I also boot to Ubuntu and I'm not sure how Ubuntu 
handles this at the moment.




I have been running Windows since Windows 7 with the hardware clock set 
to GMT.  In fact my problem has been that for the last 3-4 installs of 
Fedora, the install has set the clock to be on local time and I have had 
to reset it to be GMT. I can't speak to how Ubuntu interfaces with the 
HW clock.




regards,

Steve



--
Lester M Petrie
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 21/11/18 9:09 am, Ed Greshko wrote:

On 11/21/18 5:07 AM, Stephen Morris wrote:


Given that the front screen of the bios is displaying the time as local time, 
presumably
that means that the time settings in the bios are local time and the 
motherboard bios
doesn't provide any means to input the time as GMT, hence the bios is not set 
to GMT.

Let me try this one last time.  And it will be one last time.  I can tell you 
how to set
your system up to get consistent log entries.  It will be your choice to do it 
or not.

You have already said that the motherboard has no concept of time zones.  That 
is totally
irrelevant.  YOU know what time it is and YOU know what time zone you are in!

I look at my mobile phone and see it is 05:55 on November 21.  I know I am in 
GMT+8.  So,
GMT time is now 21:55 on November 20.  So, I go to my BIOS screen and enter 
21:55 as the
time and November 20 as the date.  The motherboard clock is NOW set to GMT!  It 
matter not
one lick if the MB has an idea of any time zone!

Step one Done.


Thinking about the data as displayed by journalctl at boot time, the time stamp 
on the
messages of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS 
assumed the
system clock was GMT and added the local zone offset to the time.

Given the fact that my /etc/adjtime has local as the last line, and from my 
recollection
I have not explicitly run the indicated commands that would set that, why is 
the OS not
honouring that specification right from boot commencement?

Set that last line to UTC.  You have now told the O/S that the HW clock is set 
to
UTC/GMT.  So now the O/S knows what you know.

Step two Done.

Make sure the the link /etc/localtime points to a correct time zone for where 
your system
is physically located.

[egreshko@meimei etc]$ ll /etc/localtime
lrwxrwxrwx. 1 root root 33 Dec 21  2017 /etc/localtime -> 
../usr/share/zoneinfo/Asia/Taipei

for ME.

(you can use timedatectl to show/set)

Step three Done.

Reboot

Done.

You will now get correct and consistent date/time stamps in your logs going 
forwad.
Previous timestamps won't be fixed.  Don't want to do that.  Well, you'll be in 
the same
situation you are now and that will be that.



With the time zone data coming from the tzdata package, are you saying that 
each year
when the local governments change when daylight saving starts and ends, that 
the tzdata
package is updated to reflect that?

Look at the changelog for the package as I showed you.

rpm -q --changelog tzdata

and you will see the dates it was updated and why it was updated.  The answer 
to your
question is obvious.


Having installed the motherboard over 12 months ago and not touched the 
time settings since, it wasn't until two days ago that I realised, 
through trial and error, that the bios date/time could be changed and 
how to do it (its changed by clicking on the time display in the bottom 
right hand corner), I was looking for options entries like other 
motherboards I've had. I can change this setting to GMT, but I also boot 
to Windows 10 and I am not sure I can trust Windows to honour the 
registry setting, plus I also boot to Ubuntu and I'm not sure how Ubuntu 
handles this at the moment.



regards,

Steve





___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/21/18 7:02 AM, Rick Stevens wrote:
> That's just the way it is (unfortunately).

And one of the myriad of reasons I don't dual boot with Windows.  VM's are good 
enough for
the few times I've got no choice in the matter. 

-- 
Right: I dislike the default color scheme Wrong: What idiot picked the default 
color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/20/18 2:09 PM, Ed Greshko wrote:
> On 11/21/18 5:07 AM, Stephen Morris wrote:
>>
>>
>> Given that the front screen of the bios is displaying the time as local 
>> time, presumably
>> that means that the time settings in the bios are local time and the 
>> motherboard bios
>> doesn't provide any means to input the time as GMT, hence the bios is not 
>> set to GMT. 
> 
> Let me try this one last time.  And it will be one last time.  I can tell you 
> how to set
> your system up to get consistent log entries.  It will be your choice to do 
> it or not.
> 
> You have already said that the motherboard has no concept of time zones.  
> That is totally
> irrelevant.  YOU know what time it is and YOU know what time zone you are in!
> 
> I look at my mobile phone and see it is 05:55 on November 21.  I know I am in 
> GMT+8.  So,
> GMT time is now 21:55 on November 20.  So, I go to my BIOS screen and enter 
> 21:55 as the
> time and November 20 as the date.  The motherboard clock is NOW set to GMT!  
> It matter not
> one lick if the MB has an idea of any time zone!
> 
> Step one Done.
> 
>> Thinking about the data as displayed by journalctl at boot time, the time 
>> stamp on the
>> messages of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS 
>> assumed the
>> system clock was GMT and added the local zone offset to the time.
>>
>> Given the fact that my /etc/adjtime has local as the last line, and from my 
>> recollection
>> I have not explicitly run the indicated commands that would set that, why is 
>> the OS not
>> honouring that specification right from boot commencement?
> 
> Set that last line to UTC.  You have now told the O/S that the HW clock is 
> set to
> UTC/GMT.  So now the O/S knows what you know.
> 
> Step two Done.
> 
> Make sure the the link /etc/localtime points to a correct time zone for where 
> your system
> is physically located.
> 
> [egreshko@meimei etc]$ ll /etc/localtime
> lrwxrwxrwx. 1 root root 33 Dec 21  2017 /etc/localtime -> 
> ../usr/share/zoneinfo/Asia/Taipei
> 
> for ME.
> 
> (you can use timedatectl to show/set)
> 
> Step three Done.
> 
> Reboot
> 
> Done.
> 
> You will now get correct and consistent date/time stamps in your logs going 
> forwad. 
> Previous timestamps won't be fixed.  Don't want to do that.  Well, you'll be 
> in the same
> situation you are now and that will be that.
> 
> 
>>
>> With the time zone data coming from the tzdata package, are you saying that 
>> each year
>> when the local governments change when daylight saving starts and ends, that 
>> the tzdata
>> package is updated to reflect that?
> 
> Look at the changelog for the package as I showed you.
> 
> rpm -q --changelog tzdata
> 
> and you will see the dates it was updated and why it was updated.  The answer 
> to your
> question is obvious.

And to make it clear, Linux expects the SYSTEM clock to be in UTC,
Windows expects it to be in local time. The SYSTEM clock is set to the
BIOS clock at boot time for both OSes. There is really no (clean) way to
make these two disparate things live together. There is a way to bugger
Windows to use a UTC clock via a registry entry, but it's a kludge.
Choose which one (Windows or Linux) is your primary OS, and set your
BIOS clock accordingly (localtime for Windows, UTC for Linux).

Linux will handle a localtime BIOS clock better. If your BIOS clock is
in local time (as Windows wants) and you boot Linux, the log entries
will have the incorrect time until chronyd drags the SYSTEM clock into
sync with UTC. The log entries will be correct from that point onwards.

So, use journalctl to look for log entries for chronyd:

journalctl -b -u chronyd

And look for the lines that indicate the clock was reset:

  chronyd<[pid]>: System clock was
stepped by  seconds

Log entries before that assume your local time is UTC, will be displayed
adjusted for your local timezone and will be off by whatever your
timezone is. Entries after that will be based on the real UTC, displayed
as your local timezone and will be correct. That's just the way it is
(unfortunately).
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-Change is inevitable, except from a vending machine.-
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/21/18 5:07 AM, Stephen Morris wrote:
>
>
> Given that the front screen of the bios is displaying the time as local time, 
> presumably
> that means that the time settings in the bios are local time and the 
> motherboard bios
> doesn't provide any means to input the time as GMT, hence the bios is not set 
> to GMT. 

Let me try this one last time.  And it will be one last time.  I can tell you 
how to set
your system up to get consistent log entries.  It will be your choice to do it 
or not.

You have already said that the motherboard has no concept of time zones.  That 
is totally
irrelevant.  YOU know what time it is and YOU know what time zone you are in!

I look at my mobile phone and see it is 05:55 on November 21.  I know I am in 
GMT+8.  So,
GMT time is now 21:55 on November 20.  So, I go to my BIOS screen and enter 
21:55 as the
time and November 20 as the date.  The motherboard clock is NOW set to GMT!  It 
matter not
one lick if the MB has an idea of any time zone!

Step one Done.

> Thinking about the data as displayed by journalctl at boot time, the time 
> stamp on the
> messages of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS 
> assumed the
> system clock was GMT and added the local zone offset to the time.
>
> Given the fact that my /etc/adjtime has local as the last line, and from my 
> recollection
> I have not explicitly run the indicated commands that would set that, why is 
> the OS not
> honouring that specification right from boot commencement?

Set that last line to UTC.  You have now told the O/S that the HW clock is set 
to
UTC/GMT.  So now the O/S knows what you know.

Step two Done.

Make sure the the link /etc/localtime points to a correct time zone for where 
your system
is physically located.

[egreshko@meimei etc]$ ll /etc/localtime
lrwxrwxrwx. 1 root root 33 Dec 21  2017 /etc/localtime -> 
../usr/share/zoneinfo/Asia/Taipei

for ME.

(you can use timedatectl to show/set)

Step three Done.

Reboot

Done.

You will now get correct and consistent date/time stamps in your logs going 
forwad. 
Previous timestamps won't be fixed.  Don't want to do that.  Well, you'll be in 
the same
situation you are now and that will be that.


>
> With the time zone data coming from the tzdata package, are you saying that 
> each year
> when the local governments change when daylight saving starts and ends, that 
> the tzdata
> package is updated to reflect that?

Look at the changelog for the package as I showed you.

rpm -q --changelog tzdata

and you will see the dates it was updated and why it was updated.  The answer 
to your
question is obvious.


-- 
Right: I dislike the default color scheme
Wrong: What idiot picked the default color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/20/18 1:07 PM, Stephen Morris wrote:
> On 19/11/18 10:13 am, Ed Greshko wrote:
>> On 11/19/18 5:08 AM, Stephen Morris wrote:
>>>  From recollection, which may not be completely accurate, the Asrock
>>> motherboard that I
>>> have now is the first motherboard I've had where the bios has not
>>> offered a setting to
>>> set the system clock to GMT/Local, and I have always set the system
>>> clock to local
>>> because Windows, which I tri-boot with, used to have issues with the
>>> system clock being
>>> GMT. Having said this, on this motherboard there isn't any option to
>>> change it, the
>>> front screen is showing local time and that time is correct for
>>> daylight savings time,
>>> even though the machine wasn't switched on when
>>> daylight savings time kicked in.
>>>
>>> I also seem to remember that there used to be an option in
>>> KDE->System Settings to
>>> configure whether or not the system clock was running local or GMT
>>> time, which I can't
>>> find now. The only setting I can find is to set the timezone and to
>>> set the date and
>>> time automatically. From memory there used to also be an option in
>>> KDE->System Setttings
>>> to have the clock maintained by a Network Time Clock where you could
>>> also specify the
>>> URL to connect to, which I used to have set to an Oceania location,
>>> but I can't find that anymore either.
>> Think about it for a moment.  Does it make any sense for a motherboard
>> to have knowledge
>> of time zones?
>>
>> The same motherboard is used all over the world and unless you update
>> the BIOS they would
>> remain static in their knowledge to time zones.
> 
> I'm not saying the motherboard bios has knowledge of timezones, what I
> am saying is that other motherboards I've had have provided the facility
> when setting the time in the bios to specify whether the time being
> input is local time or GMT time.
> 
> 
>> I've pointed out where time zone information is kept.  Those files are
>> provided by the
>> tzdata package.  Here is the start of the "changelog" for that package.
>>
>> * Mon Nov 12 2018 Patsy Griffin Franklin  - 2018g-1
>> - Rebase to tzdata-2018g
>>    Includes changes for tzdata-2018f.
>>    - Volgograd will change from UTC+03 to UTC+04 on 2018-10-28 at 02:00.
>>    - Fiji will end DST on 2019-01-13 instead of the 2019-01-20 as
>>  previously predicted.
>>    - Most of Chile will end DST on the first Saturday in April at 24:00
>>  and restart DST on the first Saturday in September at 24:00.
>>    - Morocco will change from UTC+00/+01 to permanent +01 effective
>> 2018-10-27.
>>
>> * Sat Jul 14 2018 Fedora Release Engineering
>>  - 2018e-2
>> - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
>>
>> * Wed May 16 2018 Patsy Franklin  - 2018e-1
>> - Rebase to tzdata-2018e
>>    - North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018.
>>    - In this update, the upstream project now defaults to using
>>  the "vanguard" data implementation which includes negative DST
>> offsets.
> 
> Given that the front screen of the bios is displaying the time as local
> time, presumably that means that the time settings in the bios are local
> time and the motherboard bios doesn't provide any means to input the
> time as GMT, hence the bios is not set to GMT. Thinking about the data
> as displayed by journalctl at boot time, the time stamp on the messages
> of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS assumed
> the system clock was GMT and added the local zone offset to the time.
> 
> Given the fact that my /etc/adjtime has local as the last line, and from
> my recollection I have not explicitly run the indicated commands that
> would set that, why is the OS not honouring that specification right
> from boot commencement?
> 
> With the time zone data coming from the tzdata package, are you saying
> that each year when the local governments change when daylight saving
> starts and ends, that the tzdata package is updated to reflect that?
> 
> One of the things that might be causing me confusion around this is my
> belief that the hardware/system clock is the bios time data, is that not
> correct? If that is correct, are people saying that if I issue the
> timedatectl command to specify that the RTC is not local, that it will
> adjust the bios time data to the GMT time that is relevant for the local
> timezone?

What happens is the SYSTEM clock (which is what the OS uses for internal
stuff and is expected to be in UTC) is set to the BIOS clock at boot.
AFAIK, the variable in /etc/adjtime is not looked at as /etc may not
have been mounted yet (don't know this for sure, but it seems to work
like that).

From then on, the BIOS clock is ignored as far as the OS is concerned.
NTP clients (chronyd) keep the SYSTEM clock synchronized to UTC. You
have the option of resetting the BIOS clock to the SYSTEM clock via the
hwclock command, and setting the LOCAL or UTC flag on that command will
set the BIOS clock 

Re: VPN Interface not Remaining Active With Firewall?

[Joe Zeff]

On 11/20/2018 02:07 PM, Stephen Morris wrote:
Given that the front screen of the bios is displaying the time as local 
time, presumably that means that the time settings in the bios are local 
time and the motherboard bios doesn't provide any means to input the 
time as GMT, hence the bios is not set to GMT. Thinking about the data 
as displayed by journalctl at boot time, the time stamp on the messages 
of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS assumed 
the system clock was GMT and added the local zone offset to the time.


If you want the BIOS clock set to GMT, just enter the time that why and 
tell Linux that the hardware clock is GMT.  It won't matter one bit 
because the mobo doesn't (AFAIK) use the time for anything and the only 
reason it's there is so that you don't have to reset the time every time 
you boot.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 19/11/18 10:13 am, Ed Greshko wrote:

On 11/19/18 5:08 AM, Stephen Morris wrote:

 From recollection, which may not be completely accurate, the Asrock 
motherboard that I
have now is the first motherboard I've had where the bios has not offered a 
setting to
set the system clock to GMT/Local, and I have always set the system clock to 
local
because Windows, which I tri-boot with, used to have issues with the system 
clock being
GMT. Having said this, on this motherboard there isn't any option to change it, 
the
front screen is showing local time and that time is correct for daylight 
savings time,
even though the machine wasn't switched on when daylight savings time kicked in.

I also seem to remember that there used to be an option in KDE->System Settings 
to
configure whether or not the system clock was running local or GMT time, which 
I can't
find now. The only setting I can find is to set the timezone and to set the 
date and
time automatically. From memory there used to also be an option in KDE->System 
Setttings
to have the clock maintained by a Network Time Clock where you could also 
specify the
URL to connect to, which I used to have set to an Oceania location,
but I can't find that anymore either.

Think about it for a moment.  Does it make any sense for a motherboard to have 
knowledge
of time zones?

The same motherboard is used all over the world and unless you update the BIOS 
they would
remain static in their knowledge to time zones.


I'm not saying the motherboard bios has knowledge of timezones, what I 
am saying is that other motherboards I've had have provided the facility 
when setting the time in the bios to specify whether the time being 
input is local time or GMT time.




I've pointed out where time zone information is kept.  Those files are provided 
by the
tzdata package.  Here is the start of the "changelog" for that package.

* Mon Nov 12 2018 Patsy Griffin Franklin  - 2018g-1
- Rebase to tzdata-2018g
   Includes changes for tzdata-2018f.
   - Volgograd will change from UTC+03 to UTC+04 on 2018-10-28 at 02:00.
   - Fiji will end DST on 2019-01-13 instead of the 2019-01-20 as
     previously predicted.
   - Most of Chile will end DST on the first Saturday in April at 24:00
     and restart DST on the first Saturday in September at 24:00.
   - Morocco will change from UTC+00/+01 to permanent +01 effective 2018-10-27.

* Sat Jul 14 2018 Fedora Release Engineering  - 
2018e-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

* Wed May 16 2018 Patsy Franklin  - 2018e-1
- Rebase to tzdata-2018e
   - North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018.
   - In this update, the upstream project now defaults to using
     the "vanguard" data implementation which includes negative DST offsets.


Given that the front screen of the bios is displaying the time as local 
time, presumably that means that the time settings in the bios are local 
time and the motherboard bios doesn't provide any means to input the 
time as GMT, hence the bios is not set to GMT. Thinking about the data 
as displayed by journalctl at boot time, the time stamp on the messages 
of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS assumed 
the system clock was GMT and added the local zone offset to the time.


Given the fact that my /etc/adjtime has local as the last line, and from 
my recollection I have not explicitly run the indicated commands that 
would set that, why is the OS not honouring that specification right 
from boot commencement?


With the time zone data coming from the tzdata package, are you saying 
that each year when the local governments change when daylight saving 
starts and ends, that the tzdata package is updated to reflect that?


One of the things that might be causing me confusion around this is my 
belief that the hardware/system clock is the bios time data, is that not 
correct? If that is correct, are people saying that if I issue the 
timedatectl command to specify that the RTC is not local, that it will 
adjust the bios time data to the GMT time that is relevant for the local 
timezone?



regards,

Steve





___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/18/18 1:22 PM, Stephen Morris wrote:
> On 16/11/18 12:17 pm, Rick Stevens wrote:
>> On 11/15/18 4:54 PM, Ed Greshko wrote:
>>> On 11/16/18 7:37 AM, Rick Stevens wrote:
 On 11/15/18 3:00 PM, Joe Zeff wrote:
> On 11/15/2018 03:17 PM, Rick Stevens wrote:
>> In Linux
>> case, it expects UTC. In Windows, it expects local time.
> I haven't had to deal with this for years, but if memory serves,
> there's
> a place where you can tell Linux that the hardware clock is in local
> time, not UTC.
 Ah, yes, there is. You can select the mode when you install the system,
 but the "system-config-date" utility offers a tickbox. By default, it's
 ticked and that means "System clock uses UTC".

 I also haven't done it in a while. This machine is F28, but started
 life as F18 and has been continually updated since then. The same is
 true for my other personal systems (they're current F28 or F29 and
 started as F20 or earlier). For the last 25 years or so, 95% of the
 machines I set up or use are Unix-esque in flavor, so I pretty much
 always set up UTC on the hardware clock. Sort of second nature.
>>> Well, I'm just installing an F29 MATE VM and on the TIME screen
>>> there is no tick-box
>>> to indicate that the HW clock is or isn't "local".
>>>
>>> Additionally, I could find no trace of "system-config-date" in F29.
>>>
>>> [root@meimei ~]# dnf whatprovides *bin/system-config-date
>>> Fedora 29 - x86_64 - VirtualBox    2.8 kB/s | 6.9
>>> kB 00:02
>>> Failed to synchronize cache for repo 'virtualbox', ignoring this repo.
>>> Error: No Matches found
>> And you're right. It appears mine is from(holy kapok!) F24! I told
>> you these machines have been updated from older versions.
>>
>> Ok, so you can wait until chronyd syncs, then delete the /etc/adjtime
>> file and "sudo hwclock -w --utc" to set it to UTC (default unless the
>> last line of /etc/adjtime is set to "LOCAL").
> 
> I've checked my etc/adjtime and it has the last line set to local. I
> also can't see anything obvious in that file to indicate the offset from
> local to GMT so how does hwclock know what offset to use?

Ok, so Fedora thinks your HW clock is in local time, so when your
system is booted, your system clock is also in local time. Eventually,
chronyd or some other NTP client will change your system clock (NOT your
hardware clock) to UTC. As to the data contained in the adjtime file,
do "man hwclock" and look at the "The Adjtime File" section.

As to your timezone offsets and such, that is in the timezone data.
There is a symlink, /etc/localtime, that should point to the actual
timezone data file. In my case:

/etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles

That's where the offsets, daylight saving time, whatever is kept.

> Also when I issue the hwclock command, it tells me my timezone is
> GMT+11, which is correct for daylight savings time. Given that I can't
> find any setting in KDE->System Settings any more to tell Fedora to
> allow for daylight savings time, and noting that the hwclock is correct
> for local daylight savings time, nor can I find any settings to specify
> a Network Time Clock any more that would adjust the time accordingly,
> how is my clocks correct for daylight savings time, or is the fact that
> I'm tri-booting with windows causing the clocks to be correct?

Keep in mind that your _hardware_ clock is NOT the same as your _system_
clock. Your hardware clock runs all by itself on the motherboard,
generally off a crystal controlled oscillator and powered by that coin
battery on the mobo. It is used to set the _system_ clock to the current
time at boot. The kernel and apps depend on the _system_ clock and
expect it to be in UTC.

Chronyd/NTP affect the _system_ clock. Now, depending on your settings,
at shutdown you can have the system clock reset your hardware clock so
it will be updated to the correct time as updated by chronyd (useful if
the hardware clock drifts...and a lot of them do). That's why that "UTC"
or "LOCAL" is in /etc/adjtime...so the hwclock tool knows what to do if
it's told to update the hardware clock.

> I've done a check for system-config-date and it doesn't exist on my F28
> system either, but then I did in the past have to re-install F26 from
> scratch, so that may have removed it.

From what I gather, they stopped including it in F26. Don't know why...
it's a pretty useful tool.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-When you don't know what to do, walk fast and look worried. -
--
___
users mailing list -- users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/19/18 9:05 PM, Louis Lagendijk wrote:
> On Mon, 2018-11-19 at 06:24 +0800, Ed Greshko wrote:
>> On 11/19/18 5:51 AM, Stephen Morris wrote:
>>> Sure, but if the user is in the United Kingdom where they use GMT,
>>> then presumably they
>>> would run their entire system in GMT, whereas other locations may
>>> or may not want to, so
>>> the motherboard should provide that option, and I have had
>>> motherboard that do offer the
>>> option, and I have always set them to local time.
>> People in the "UK" won't use GMT/UTC  as they also "spring forward"
>> and "fall back".
>>
>> The time zone of a system is establish by the symbolic link
>> /etc/localtime.
>>
>> Their link will be set to "../usr/share/zoneinfo/Europe/London"
>>
>>> If the time configuration is being set by the OS, and F28 doesn't
>>> seem to have the
>>> options to do that setting, especially for daylight savings time,
>>> how does daylight
>>> savings time get set/unset correctly, or is the fact that this F28
>>> system has been
>>> upgraded from older Fedora distributions that did have the options,
>>> and the option to
>>> tie the time maintenance to a Network Time Clock, that those
>>> options have been
>>> retained but hidden by F28? 
>> The zoneinfo files have all the info necessary to determine when
>> "daylight" time begins
>> and ends.
> and if you want to run the hwclock to be in local time rather then UTC
> you can set the system to honor that from the CLI:
>
> [louis@travel ~]$ timedatectl --help
> timedatectl [OPTIONS...] COMMAND ...
>
> Query or change system time and date settings.
>
>   -h --helpShow this help message
>  --version Show package version
>  --no-pagerDo not pipe output into a pager
>  --no-ask-password Do not prompt for password
>   -H --host=[USER@]HOSTOperate on remote host
>   -M --machine=CONTAINER   Operate on local container
>  --adjust-system-clock Adjust system clock when changing local RTC
> mode
>  --monitor Monitor status of systemd-timesyncd
>   -p --property=NAME   Show only properties by this name
>   -a --all Show all properties, including empty ones
>  --value   When showing properties, only print the
> value
>
> Commands:
>   status   Show current time settings
>   show Show properties of systemd-timedated
>   set-time TIMESet system time
>   set-timezone ZONESet system time zone
>   list-timezones   Show known time zones
>   set-local-rtc BOOL   Control whether RTC is in local time
>   set-ntp BOOL Enable or disable network time
> synchronization
>
> systemd-timesyncd Commands:
>   timesync-status  Show status of systemd-timesyncd
>   show-timesyncShow properties of systemd-timesyncd
> [louis@travel ~]$ 
>
> so a "timedatectl set-local-rtc yes (or so, I am not sure what boolen
> values are accepted) should do the trick. I still recommend UTC though
>

If you do that it will modify /etc/adjtime to add "LOCAL" to the end of the 
file.  The
next time you run "timedatectl" you'll get this warning.

Warning: The system is configured to read the RTC time in the local time zone.
 This mode cannot be fully supported. It will create various problems
 with time zone changes and daylight saving time adjustments. The RTC
 time is never updated, it relies on external facilities to maintain it.
 If at all possible, use RTC in UTC by calling
 'timedatectl set-local-rtc 0'.

The goal here is to have all log entries easy to search and have no ambiguity.  
The proven
way to do that is set the hardware clock on the BIOS equal to the time in 
UTC/GMT.


-- 
Right: I dislike the default color scheme Wrong: What idiot picked the default 
color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Louis Lagendijk]

On Mon, 2018-11-19 at 06:24 +0800, Ed Greshko wrote:
> On 11/19/18 5:51 AM, Stephen Morris wrote:
> > Sure, but if the user is in the United Kingdom where they use GMT,
> > then presumably they
> > would run their entire system in GMT, whereas other locations may
> > or may not want to, so
> > the motherboard should provide that option, and I have had
> > motherboard that do offer the
> > option, and I have always set them to local time.
> 
> People in the "UK" won't use GMT/UTC  as they also "spring forward"
> and "fall back".
> 
> The time zone of a system is establish by the symbolic link
> /etc/localtime.
> 
> Their link will be set to "../usr/share/zoneinfo/Europe/London"
> 
> > If the time configuration is being set by the OS, and F28 doesn't
> > seem to have the
> > options to do that setting, especially for daylight savings time,
> > how does daylight
> > savings time get set/unset correctly, or is the fact that this F28
> > system has been
> > upgraded from older Fedora distributions that did have the options,
> > and the option to
> > tie the time maintenance to a Network Time Clock, that those
> > options have been
> > retained but hidden by F28? 
> 
> The zoneinfo files have all the info necessary to determine when
> "daylight" time begins
> and ends.

and if you want to run the hwclock to be in local time rather then UTC
you can set the system to honor that from the CLI:

[louis@travel ~]$ timedatectl --help
timedatectl [OPTIONS...] COMMAND ...

Query or change system time and date settings.

  -h --helpShow this help message
 --version Show package version
 --no-pagerDo not pipe output into a pager
 --no-ask-password Do not prompt for password
  -H --host=[USER@]HOSTOperate on remote host
  -M --machine=CONTAINER   Operate on local container
 --adjust-system-clock Adjust system clock when changing local RTC
mode
 --monitor Monitor status of systemd-timesyncd
  -p --property=NAME   Show only properties by this name
  -a --all Show all properties, including empty ones
 --value   When showing properties, only print the
value

Commands:
  status   Show current time settings
  show Show properties of systemd-timedated
  set-time TIMESet system time
  set-timezone ZONESet system time zone
  list-timezones   Show known time zones
  set-local-rtc BOOL   Control whether RTC is in local time
  set-ntp BOOL Enable or disable network time
synchronization

systemd-timesyncd Commands:
  timesync-status  Show status of systemd-timesyncd
  show-timesyncShow properties of systemd-timesyncd
[louis@travel ~]$ 

so a "timedatectl set-local-rtc yes (or so, I am not sure what boolen
values are accepted) should do the trick. I still recommend UTC though



___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Samuel Sieb]

On 11/18/18 2:24 PM, Ed Greshko wrote:

Right:  I dislike the default color scheme
Wron:  What idiot picked the default color scheme


Thank you!  It's sad that it's necessary to point that out though.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/19/18 5:08 AM, Stephen Morris wrote:
>>
> From recollection, which may not be completely accurate, the Asrock 
> motherboard that I
> have now is the first motherboard I've had where the bios has not offered a 
> setting to
> set the system clock to GMT/Local, and I have always set the system clock to 
> local
> because Windows, which I tri-boot with, used to have issues with the system 
> clock being
> GMT. Having said this, on this motherboard there isn't any option to change 
> it, the
> front screen is showing local time and that time is correct for daylight 
> savings time,
> even though the machine wasn't switched on when daylight savings time kicked 
> in.
>
> I also seem to remember that there used to be an option in KDE->System 
> Settings to
> configure whether or not the system clock was running local or GMT time, 
> which I can't
> find now. The only setting I can find is to set the timezone and to set the 
> date and
> time automatically. From memory there used to also be an option in 
> KDE->System Setttings
> to have the clock maintained by a Network Time Clock where you could also 
> specify the
> URL to connect to, which I used to have set to an Oceania location,
> but I can't find that anymore either. 

Think about it for a moment.  Does it make any sense for a motherboard to have 
knowledge
of time zones?

The same motherboard is used all over the world and unless you update the BIOS 
they would
remain static in their knowledge to time zones.

I've pointed out where time zone information is kept.  Those files are provided 
by the
tzdata package.  Here is the start of the "changelog" for that package.

* Mon Nov 12 2018 Patsy Griffin Franklin  - 2018g-1
- Rebase to tzdata-2018g
  Includes changes for tzdata-2018f.
  - Volgograd will change from UTC+03 to UTC+04 on 2018-10-28 at 02:00.
  - Fiji will end DST on 2019-01-13 instead of the 2019-01-20 as
    previously predicted.
  - Most of Chile will end DST on the first Saturday in April at 24:00
    and restart DST on the first Saturday in September at 24:00.
  - Morocco will change from UTC+00/+01 to permanent +01 effective 2018-10-27.

* Sat Jul 14 2018 Fedora Release Engineering  - 
2018e-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

* Wed May 16 2018 Patsy Franklin  - 2018e-1
- Rebase to tzdata-2018e
  - North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018.
  - In this update, the upstream project now defaults to using
    the "vanguard" data implementation which includes negative DST offsets.


-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/19/18 5:51 AM, Stephen Morris wrote:
> Sure, but if the user is in the United Kingdom where they use GMT, then 
> presumably they
> would run their entire system in GMT, whereas other locations may or may not 
> want to, so
> the motherboard should provide that option, and I have had motherboard that 
> do offer the
> option, and I have always set them to local time.

People in the "UK" won't use GMT/UTC  as they also "spring forward" and "fall 
back".

The time zone of a system is establish by the symbolic link /etc/localtime.

Their link will be set to "../usr/share/zoneinfo/Europe/London"

>
> If the time configuration is being set by the OS, and F28 doesn't seem to 
> have the
> options to do that setting, especially for daylight savings time, how does 
> daylight
> savings time get set/unset correctly, or is the fact that this F28 system has 
> been
> upgraded from older Fedora distributions that did have the options, and the 
> option to
> tie the time maintenance to a Network Time Clock, that those options have been
> retained but hidden by F28? 

The zoneinfo files have all the info necessary to determine when "daylight" 
time begins
and ends.

-- 
Right:  I dislike the default color scheme
Wron:  What idiot picked the default color scheme
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 19/11/18 8:21 am, Joe Zeff wrote:

On 11/18/2018 02:08 PM, Stephen Morris wrote:
 From recollection, which may not be completely accurate, the Asrock 
motherboard that I have now is the first motherboard I've had where 
the bios has not offered a setting to set the system clock to 
GMT/Local, and I have always set the system clock to local because 
Windows, which I tri-boot with, used to have issues with the system 
clock being GMT. Having said this, on this motherboard there isn't 
any option to change it, the front screen is showing local time and 
that time is correct for daylight savings time, even though the 
machine wasn't switched on when daylight savings time kicked in.


If you think about it, there's no reason for the mobo to know what 
timezone it's in.  All it has to do is keep track of the time, and let 
the OS worry about timezones, DST and other time/date related stuff.


Sure, but if the user is in the United Kingdom where they use GMT, then 
presumably they would run their entire system in GMT, whereas other 
locations may or may not want to, so the motherboard should provide that 
option, and I have had motherboard that do offer the option, and I have 
always set them to local time.


If the time configuration is being set by the OS, and F28 doesn't seem 
to have the options to do that setting, especially for daylight savings 
time, how does daylight savings time get set/unset correctly, or is the 
fact that this F28 system has been upgraded from older Fedora 
distributions that did have the options, and the option to tie the time 
maintenance to a Network Time Clock, that those options have been 
retained but hidden by F28?



regards,

Steve



___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 16/11/18 12:17 pm, Rick Stevens wrote:

On 11/15/18 4:54 PM, Ed Greshko wrote:

On 11/16/18 7:37 AM, Rick Stevens wrote:

On 11/15/18 3:00 PM, Joe Zeff wrote:

On 11/15/2018 03:17 PM, Rick Stevens wrote:

In Linux
case, it expects UTC. In Windows, it expects local time.

I haven't had to deal with this for years, but if memory serves, there's
a place where you can tell Linux that the hardware clock is in local
time, not UTC.

Ah, yes, there is. You can select the mode when you install the system,
but the "system-config-date" utility offers a tickbox. By default, it's
ticked and that means "System clock uses UTC".

I also haven't done it in a while. This machine is F28, but started
life as F18 and has been continually updated since then. The same is
true for my other personal systems (they're current F28 or F29 and
started as F20 or earlier). For the last 25 years or so, 95% of the
machines I set up or use are Unix-esque in flavor, so I pretty much
always set up UTC on the hardware clock. Sort of second nature.

Well, I'm just installing an F29 MATE VM and on the TIME screen there is 
no tick-box
to indicate that the HW clock is or isn't "local".

Additionally, I could find no trace of "system-config-date" in F29.

[root@meimei ~]# dnf whatprovides *bin/system-config-date
Fedora 29 - x86_64 - VirtualBox    2.8 kB/s | 6.9 kB 00:02
Failed to synchronize cache for repo 'virtualbox', ignoring this repo.
Error: No Matches found

And you're right. It appears mine is from(holy kapok!) F24! I told
you these machines have been updated from older versions.

Ok, so you can wait until chronyd syncs, then delete the /etc/adjtime
file and "sudo hwclock -w --utc" to set it to UTC (default unless the
last line of /etc/adjtime is set to "LOCAL").


I've checked my etc/adjtime and it has the last line set to local. I 
also can't see anything obvious in that file to indicate the offset from 
local to GMT so how does hwclock know what offset to use?


Also when I issue the hwclock command, it tells me my timezone is 
GMT+11, which is correct for daylight savings time. Given that I can't 
find any setting in KDE->System Settings any more to tell Fedora to 
allow for daylight savings time, and noting that the hwclock is correct 
for local daylight savings time, nor can I find any settings to specify 
a Network Time Clock any more that would adjust the time accordingly, 
how is my clocks correct for daylight savings time, or is the fact that 
I'm tri-booting with windows causing the clocks to be correct?


I've done a check for system-config-date and it doesn't exist on my F28 
system either, but then I did in the past have to re-install F26 from 
scratch, so that may have removed it.



regards,

Steve



--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
- "Celibacy is not hereditary."  -
-  -- Guy Goden  -
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Joe Zeff]

On 11/18/2018 02:08 PM, Stephen Morris wrote:
 From recollection, which may not be completely accurate, the Asrock 
motherboard that I have now is the first motherboard I've had where the 
bios has not offered a setting to set the system clock to GMT/Local, and 
I have always set the system clock to local because Windows, which I 
tri-boot with, used to have issues with the system clock being GMT. 
Having said this, on this motherboard there isn't any option to change 
it, the front screen is showing local time and that time is correct for 
daylight savings time, even though the machine wasn't switched on when 
daylight savings time kicked in.


If you think about it, there's no reason for the mobo to know what 
timezone it's in.  All it has to do is keep track of the time, and let 
the OS worry about timezones, DST and other time/date related stuff.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 16/11/18 1:12 pm, Tony Nelson wrote:

On 18-11-15 18:00:14, Joe Zeff wrote:

On 11/15/2018 03:17 PM, Rick Stevens wrote:

In Linux
case, it expects UTC. In Windows, it expects local time.


I haven't had to deal with this for years, but if memory serves, 
there's a

place where you can tell Linux that the hardware clock is in local time,
not UTC.


man hwclock:

   LOCAL vs UTC
   Keeping the Hardware Clock in a  local  timescale  causes 
inconsistent

   daylight saving time results:

   · If  Linux  is  running during a daylight saving time change, 
the time

 written to the Hardware Clock will be adjusted for the change.

   · If Linux is NOT running during a daylight  saving  time 
change,  the
 time  read  from  the  Hardware  Clock  will  NOT be adjusted 
for the

 change.

   The Hardware Clock on an ISA compatible system keeps only a  
date  and
   time,  it  has  no  concept of timezone nor daylight saving. 
Therefore,
   when hwclock is told that it is in local time, it assumes it is 
in  the
   'correct' local time and makes no adjustments to the time read 
from it.


   Linux  handles daylight saving time changes transparently only 
when the
   Hardware Clock is kept in the UTC timescale. Doing so is made 
easy  for
   system  administrators as hwclock uses local time for its 
output and as

   the argument to the --date option.

   POSIX systems, like Linux, are designed to have the System 
Clock  oper‐
   ate in the UTC timescale. The Hardware Clock's purpose is to 
initialize

   the System Clock, so also keeping it in UTC makes sense.

   Linux does, however, attempt to accommodate the Hardware Clock 
being in
   the local timescale. This is primarily for dual-booting with 
older ver‐
   sions of MS Windows. From Windows 7 on,  the 
RealTimeIsUniversal  reg‐
   istry key is supposed to be working properly so that its 
Hardware Clock

   can be kept in UTC.

From recollection, which may not be completely accurate, the Asrock 
motherboard that I have now is the first motherboard I've had where the 
bios has not offered a setting to set the system clock to GMT/Local, and 
I have always set the system clock to local because Windows, which I 
tri-boot with, used to have issues with the system clock being GMT. 
Having said this, on this motherboard there isn't any option to change 
it, the front screen is showing local time and that time is correct for 
daylight savings time, even though the machine wasn't switched on when 
daylight savings time kicked in.


I also seem to remember that there used to be an option in KDE->System 
Settings to configure whether or not the system clock was running local 
or GMT time, which I can't find now. The only setting I can find is to 
set the timezone and to set the date and time automatically. From memory 
there used to also be an option in KDE->System Setttings to have the 
clock maintained by a Network Time Clock where you could also specify 
the URL to connect to, which I used to have set to an Oceania location, 
but I can't find that anymore either.



regards,

Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Tony Nelson]

On 18-11-15 18:00:14, Joe Zeff wrote:

On 11/15/2018 03:17 PM, Rick Stevens wrote:

In Linux
case, it expects UTC. In Windows, it expects local time.


I haven't had to deal with this for years, but if memory serves,  
there's a
place where you can tell Linux that the hardware clock is in local  
time,

not UTC.


man hwclock:

   LOCAL vs UTC
   Keeping the Hardware Clock in a  local  timescale  causes   
inconsistent

   daylight saving time results:

   · If  Linux  is  running during a daylight saving time change,  
the time

 written to the Hardware Clock will be adjusted for the change.

   · If Linux is NOT running during a daylight  saving  time   
change,  the
 time  read  from  the  Hardware  Clock  will  NOT be adjusted  
for the

 change.

   The Hardware Clock on an ISA compatible system keeps only  a   
date  and
   time,  it  has  no  concept of timezone nor daylight saving.  
Therefore,
   when hwclock is told that it is in local time, it assumes it is  
in  the
   'correct' local time and makes no adjustments to the time read  
from it.


   Linux  handles daylight saving time changes transparently only  
when the
   Hardware Clock is kept in the UTC timescale. Doing so is made  
easy  for
   system  administrators as hwclock uses local time for its  
output and as

   the argument to the --date option.

   POSIX systems, like Linux, are designed to have the System  
Clock  oper‐
   ate in the UTC timescale. The Hardware Clock's purpose is to  
initialize

   the System Clock, so also keeping it in UTC makes sense.

   Linux does, however, attempt to accommodate the Hardware Clock  
being in
   the local timescale. This is primarily for dual-booting with  
older ver‐
   sions of MS Windows. From Windows 7 on,  the   
RealTimeIsUniversal  reg‐
   istry key is supposed to be working properly so that its  
Hardware Clock

   can be kept in UTC.

--

TonyN.:'   
  '  
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Joe Zeff]

On 11/15/2018 06:32 PM, Ed Greshko wrote:

Why don't you give it a try and show me it exits?

https://koji.fedoraproject.org/koji/packageinfo?packageID=11

Shows the last time this package was supplied was in F25.

Kindly check your work before making suggestions?


I did, but I'm working on my laptop after a move and it's still on F26. 
It's not getting upgraded until after my desktop is up and running so 
that I always have a working system.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/16/18 9:17 AM, Rick Stevens wrote:
> On 11/15/18 4:54 PM, Ed Greshko wrote:
>>
>> Well, I'm just installing an F29 MATE VM and on the TIME screen there 
>> is no tick-box
>> to indicate that the HW clock is or isn't "local". 
>>
>> Additionally, I could find no trace of "system-config-date" in F29.
>>
>> [root@meimei ~]# dnf whatprovides *bin/system-config-date
>> Fedora 29 - x86_64 - VirtualBox    2.8 kB/s | 6.9 kB 
>> 00:02   
>> Failed to synchronize cache for repo 'virtualbox', ignoring this repo.
>> Error: No Matches found
> And you're right. It appears mine is from(holy kapok!) F24! I told
> you these machines have been updated from older versions.

I keep a copy of the LVM GUI tool from F23ish.  It came in handy...but I've not 
used it in
a while.


> Ok, so you can wait until chronyd syncs, then delete the /etc/adjtime
> file and "sudo hwclock -w --utc" to set it to UTC (default unless the
> last line of /etc/adjtime is set to "LOCAL").
>

Ah, I forgot about that file.  I wonder if that is what the tick-box in the 
tool changes?


-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/16/18 9:26 AM, Joe Zeff wrote:
> On 11/15/2018 05:54 PM, Ed Greshko wrote:
>> Additionally, I could find no trace of "system-config-date" in F29.
>>
>> [root@meimei ~]# dnf whatprovides *bin/system-config-date
>> Fedora 29 - x86_64 - VirtualBox    2.8 kB/s | 6.9 kB 
>> 00:02
>> Failed to synchronize cache for repo 'virtualbox', ignoring this repo.
>> Error: No Matches found
>
> Try it without the path and see if that brings it up.

Why don't you give it a try and show me it exits?

https://koji.fedoraproject.org/koji/packageinfo?packageID=11

Shows the last time this package was supplied was in F25.

Kindly check your work before making suggestions?


-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Joe Zeff]

On 11/15/2018 05:54 PM, Ed Greshko wrote:

Additionally, I could find no trace of "system-config-date" in F29.

[root@meimei ~]# dnf whatprovides *bin/system-config-date
Fedora 29 - x86_64 - VirtualBox    2.8 kB/s | 6.9 kB 00:02
Failed to synchronize cache for repo 'virtualbox', ignoring this repo.
Error: No Matches found


Try it without the path and see if that brings it up.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/15/18 4:54 PM, Ed Greshko wrote:
> On 11/16/18 7:37 AM, Rick Stevens wrote:
>> On 11/15/18 3:00 PM, Joe Zeff wrote:
>>> On 11/15/2018 03:17 PM, Rick Stevens wrote:
 In Linux
 case, it expects UTC. In Windows, it expects local time.
>>> I haven't had to deal with this for years, but if memory serves, there's
>>> a place where you can tell Linux that the hardware clock is in local
>>> time, not UTC.
>> Ah, yes, there is. You can select the mode when you install the system,
>> but the "system-config-date" utility offers a tickbox. By default, it's
>> ticked and that means "System clock uses UTC".
>>
>> I also haven't done it in a while. This machine is F28, but started
>> life as F18 and has been continually updated since then. The same is
>> true for my other personal systems (they're current F28 or F29 and
>> started as F20 or earlier). For the last 25 years or so, 95% of the
>> machines I set up or use are Unix-esque in flavor, so I pretty much
>> always set up UTC on the hardware clock. Sort of second nature.
> 
> Well, I'm just installing an F29 MATE VM and on the TIME screen there is 
> no tick-box
> to indicate that the HW clock is or isn't "local". 
> 
> Additionally, I could find no trace of "system-config-date" in F29.
> 
> [root@meimei ~]# dnf whatprovides *bin/system-config-date
> Fedora 29 - x86_64 - VirtualBox    2.8 kB/s | 6.9 kB 
> 00:02   
> Failed to synchronize cache for repo 'virtualbox', ignoring this repo.
> Error: No Matches found

And you're right. It appears mine is from(holy kapok!) F24! I told
you these machines have been updated from older versions.

Ok, so you can wait until chronyd syncs, then delete the /etc/adjtime
file and "sudo hwclock -w --utc" to set it to UTC (default unless the
last line of /etc/adjtime is set to "LOCAL").
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
- "Celibacy is not hereditary."  -
-  -- Guy Goden  -
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/16/18 7:37 AM, Rick Stevens wrote:
> On 11/15/18 3:00 PM, Joe Zeff wrote:
>> On 11/15/2018 03:17 PM, Rick Stevens wrote:
>>> In Linux
>>> case, it expects UTC. In Windows, it expects local time.
>> I haven't had to deal with this for years, but if memory serves, there's
>> a place where you can tell Linux that the hardware clock is in local
>> time, not UTC.
> Ah, yes, there is. You can select the mode when you install the system,
> but the "system-config-date" utility offers a tickbox. By default, it's
> ticked and that means "System clock uses UTC".
>
> I also haven't done it in a while. This machine is F28, but started
> life as F18 and has been continually updated since then. The same is
> true for my other personal systems (they're current F28 or F29 and
> started as F20 or earlier). For the last 25 years or so, 95% of the
> machines I set up or use are Unix-esque in flavor, so I pretty much
> always set up UTC on the hardware clock. Sort of second nature.

Well, I'm just installing an F29 MATE VM and on the TIME screen there is 
no tick-box
to indicate that the HW clock is or isn't "local". 

Additionally, I could find no trace of "system-config-date" in F29.

[root@meimei ~]# dnf whatprovides *bin/system-config-date
Fedora 29 - x86_64 - VirtualBox    2.8 kB/s | 6.9 kB 00:02  
 
Failed to synchronize cache for repo 'virtualbox', ignoring this repo.
Error: No Matches found

-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/15/18 3:00 PM, Joe Zeff wrote:
> On 11/15/2018 03:17 PM, Rick Stevens wrote:
>> In Linux
>> case, it expects UTC. In Windows, it expects local time.
> 
> I haven't had to deal with this for years, but if memory serves, there's
> a place where you can tell Linux that the hardware clock is in local
> time, not UTC.

Ah, yes, there is. You can select the mode when you install the system,
but the "system-config-date" utility offers a tickbox. By default, it's
ticked and that means "System clock uses UTC".

I also haven't done it in a while. This machine is F28, but started
life as F18 and has been continually updated since then. The same is
true for my other personal systems (they're current F28 or F29 and
started as F20 or earlier). For the last 25 years or so, 95% of the
machines I set up or use are Unix-esque in flavor, so I pretty much
always set up UTC on the hardware clock. Sort of second nature.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-   Fear is finding a ".vbs" script in your Inbox-
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Joe Zeff]

On 11/15/2018 03:17 PM, Rick Stevens wrote:

In Linux
case, it expects UTC. In Windows, it expects local time.


I haven't had to deal with this for years, but if memory serves, there's 
a place where you can tell Linux that the hardware clock is in local 
time, not UTC.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/15/18 2:40 PM, Ed Greshko wrote:
> On 11/16/18 6:17 AM, Rick Stevens wrote:
>> On 11/15/18 2:00 PM, Ed Greshko wrote:
>>> On 11/16/18 4:50 AM, Stephen Morris wrote:
 On 14/11/18 8:46 am, Ed Greshko wrote:
> On 11/14/18 5:32 AM, Stephen Morris wrote:
>> My hardware clock is running a couple of seconds slow as well.
>>
>> Just as a matter of curiosity, when you say if you issue hwclock from 
>> the bios (how have
>> you done that) what does journalctl show for the same time? Does it 
>> show, using your
>> example, 2018-11-12 21:47 or does it show 2018-11-13 21:47?
> I did not say what you think I said.
>
> I said, "But if I reboot and go into the BIOS it will show 2018-11-12 
> 21:47", which I
> thought was clear.
>
> To expound.  I reboot, enter F2 when the Boot (not grub) splash screen 
> comes up and enter
> the BIOS setup of the motherboard.
 I've checked my bios and the bios home screen shows the date and time as 
 local time (I
 also don't remember seeing any functionality on any bios screen to change 
 that. I have
 had motherboards in the past that have provided that functionality.).
>>> There must be a way to change it since someone must have set it at some 
>>> point in time.
>>>
>>> Until you get it set to GMT/UTC you're going to have strange times in your 
>>> logs.
>> The vast majority of motherboards I've seen don't have a timezone
>> setting on them, just a date and time and it's up to you to sort out
>> what GMT/UTC is relative to your local time and enter it (the UTC data)
>> appropriately.
> 
> Maybe there is a disconnect on wording.
> 
> Yes, none of the BIOS on my systems have a TimeZone setting.
> 
> What I'm trying to say is that when you are in the BIOS screen the Date/Time 
> should be
> that of GMT/UTC and not local.

Yes, that's what I'm saying. _YOU_ have to sort out what the correct UTC
is and enter it. The firmware (BIOS/UEFI) has no way of doing the offset
for you unless it has a timezone setting as well (most that I've seen
don't), so it's a manual job.

> I've never seen a BIOS that didn't have a way to change Date/Time.  But, if 
> so, what is
> below should work for him.
> 
>> I guess alternately, you could wait for cronyd or whatever to sync the
>> system clock to UTC, then use "sudo hwclock -w" to set the hardware
>> clock from the system clock. The journal and everything is based on
>> the system clock, which is what cronyd "pokes". The hardware clock is
>> just there to give the system clock a starting point at boot. In Linux
>> case, it expects UTC. In Windows, it expects local time.
>>
> 
> I also don't dual boot, VM's work for me, but I seem to remember when you 
> have your system
> set up as Linux would like it then Windows has fits.  :-) :-)

Yup.

> Coffee, I need Coffee!

Me, too! Black. And strong! If you don't have to chew, it ain't strong
enough!
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
- Warning:  You are logged into reality as the root user...  -
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/16/18 6:17 AM, Rick Stevens wrote:
> On 11/15/18 2:00 PM, Ed Greshko wrote:
>> On 11/16/18 4:50 AM, Stephen Morris wrote:
>>> On 14/11/18 8:46 am, Ed Greshko wrote:
 On 11/14/18 5:32 AM, Stephen Morris wrote:
> My hardware clock is running a couple of seconds slow as well.
>
> Just as a matter of curiosity, when you say if you issue hwclock from the 
> bios (how have
> you done that) what does journalctl show for the same time? Does it show, 
> using your
> example, 2018-11-12 21:47 or does it show 2018-11-13 21:47?
 I did not say what you think I said.

 I said, "But if I reboot and go into the BIOS it will show 2018-11-12 
 21:47", which I
 thought was clear.

 To expound.  I reboot, enter F2 when the Boot (not grub) splash screen 
 comes up and enter
 the BIOS setup of the motherboard.
>>> I've checked my bios and the bios home screen shows the date and time as 
>>> local time (I
>>> also don't remember seeing any functionality on any bios screen to change 
>>> that. I have
>>> had motherboards in the past that have provided that functionality.).
>> There must be a way to change it since someone must have set it at some 
>> point in time.
>>
>> Until you get it set to GMT/UTC you're going to have strange times in your 
>> logs.
> The vast majority of motherboards I've seen don't have a timezone
> setting on them, just a date and time and it's up to you to sort out
> what GMT/UTC is relative to your local time and enter it (the UTC data)
> appropriately.

Maybe there is a disconnect on wording.

Yes, none of the BIOS on my systems have a TimeZone setting.

What I'm trying to say is that when you are in the BIOS screen the Date/Time 
should be
that of GMT/UTC and not local.

I've never seen a BIOS that didn't have a way to change Date/Time.  But, if so, 
what is
below should work for him.

> I guess alternately, you could wait for cronyd or whatever to sync the
> system clock to UTC, then use "sudo hwclock -w" to set the hardware
> clock from the system clock. The journal and everything is based on
> the system clock, which is what cronyd "pokes". The hardware clock is
> just there to give the system clock a starting point at boot. In Linux
> case, it expects UTC. In Windows, it expects local time.
>

I also don't dual boot, VM's work for me, but I seem to remember when you have 
your system
set up as Linux would like it then Windows has fits.  :-) :-)

Coffee, I need Coffee!

-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/15/18 2:00 PM, Ed Greshko wrote:
> On 11/16/18 4:50 AM, Stephen Morris wrote:
>> On 14/11/18 8:46 am, Ed Greshko wrote:
>>> On 11/14/18 5:32 AM, Stephen Morris wrote:
 My hardware clock is running a couple of seconds slow as well.

 Just as a matter of curiosity, when you say if you issue hwclock from the 
 bios (how have
 you done that) what does journalctl show for the same time? Does it show, 
 using your
 example, 2018-11-12 21:47 or does it show 2018-11-13 21:47?
>>> I did not say what you think I said.
>>>
>>> I said, "But if I reboot and go into the BIOS it will show 2018-11-12 
>>> 21:47", which I
>>> thought was clear.
>>>
>>> To expound.  I reboot, enter F2 when the Boot (not grub) splash screen 
>>> comes up and enter
>>> the BIOS setup of the motherboard.
>>
>> I've checked my bios and the bios home screen shows the date and time as 
>> local time (I
>> also don't remember seeing any functionality on any bios screen to change 
>> that. I have
>> had motherboards in the past that have provided that functionality.).
> 
> There must be a way to change it since someone must have set it at some point 
> in time.
> 
> Until you get it set to GMT/UTC you're going to have strange times in your 
> logs.

The vast majority of motherboards I've seen don't have a timezone
setting on them, just a date and time and it's up to you to sort out
what GMT/UTC is relative to your local time and enter it (the UTC data)
appropriately.

I guess alternately, you could wait for cronyd or whatever to sync the
system clock to UTC, then use "sudo hwclock -w" to set the hardware
clock from the system clock. The journal and everything is based on
the system clock, which is what cronyd "pokes". The hardware clock is
just there to give the system clock a starting point at boot. In Linux
case, it expects UTC. In Windows, it expects local time.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-Physics is like sex ... it may have some practical uses, but-
-that's not why we do it. -- Richard Feynman
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/16/18 4:50 AM, Stephen Morris wrote:
> On 14/11/18 8:46 am, Ed Greshko wrote:
>> On 11/14/18 5:32 AM, Stephen Morris wrote:
>>> My hardware clock is running a couple of seconds slow as well.
>>>
>>> Just as a matter of curiosity, when you say if you issue hwclock from the 
>>> bios (how have
>>> you done that) what does journalctl show for the same time? Does it show, 
>>> using your
>>> example, 2018-11-12 21:47 or does it show 2018-11-13 21:47?
>> I did not say what you think I said.
>>
>> I said, "But if I reboot and go into the BIOS it will show 2018-11-12 
>> 21:47", which I
>> thought was clear.
>>
>> To expound.  I reboot, enter F2 when the Boot (not grub) splash screen comes 
>> up and enter
>> the BIOS setup of the motherboard.
>
> I've checked my bios and the bios home screen shows the date and time as 
> local time (I
> also don't remember seeing any functionality on any bios screen to change 
> that. I have
> had motherboards in the past that have provided that functionality.).

There must be a way to change it since someone must have set it at some point 
in time.

Until you get it set to GMT/UTC you're going to have strange times in your logs.


>
> Going into a terminal shell once KDE had started up and issuing the hwclock 
> command I
> get the following output which is not an issue:
>
> bash-4.4$ sudo hwclock
> 2018-11-16 07:21:53.014617+11:00
>
> From the same terminal, issuing   journalctl -b 0   I get the following 
> messages as the
> first set of messages it displays. The time at the beginning of the messages 
> as to when
> the system was booted, being 18:17:18, is correct as GMT time relative to my 
> time zone,
> which is GMT+11 as hwclock shows, but the date of Nov 16 is wrong for GMT, it 
> should be
> Nov 15. The correct GMT time for my time zone relative to when I booted is   
> Nov 15
> 18:17:18. Hence the question of exactly what is that format supposed to be?
>
> When looking at journalctl messages to try to determine why my vpns are 
> timing out,
> where the vpn was started after KDE was active, the time in the messages were 
> definitely
> local time.
>
> bash-4.4$ journalctl -b 0
> -- Logs begin at Wed 2016-01-06 07:29:31 AEDT, end at Fri 2018-11-16 07:22:16 
> AEDT. --
> Nov 16 18:17:18 localhost.localdomain kernel: Linux version 
> 4.18.14-200.fc28.x86_64
> (mockbu...@bkernel03.phx2.fedoraproject.org) (gcc version 8.1.1 20180712 (Red 
> Hat
> 8.1.1-5) (GCC)) #1 SMP Mon Oct >
> Nov 16 18:17:18 localhost.localdomain kernel: Command line:
> BOOT_IMAGE=/vmlinuz-4.18.14-200.fc28.x86_64
> root=UUID=8dae94dc-1c3e-4be1-b1f8-b146f094314b ro rd.driver.blacklist=nouveau
> modprobe.blackl>
> Nov 16 18:17:18 localhost.localdomain kernel: random: get_random_u32 called 
> from
> bsp_init_amd+0x20b/0x2b0 with crng_init=0
> Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: Supporting XSAVE 
> feature 0x001:
> 'x87 floating point registers'
> Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: Supporting XSAVE 
> feature 0x002:
> 'SSE registers'
> Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: Supporting XSAVE 
> feature 0x004:
> 'AVX registers'
> Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: xstate_offset[2]:  576,
> xstate_sizes[2]:  256
> Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: Enabled xstate 
> features 0x7,
> context size is 832 bytes, using 'standard' format.
> Nov 16 18:17:18 localhost.localdomain kernel: BIOS-provided physical RAM map:
>
>
> regards,
>
> Steve
>
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org


-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 14/11/18 10:03 am, Samuel Sieb wrote:

On 11/13/18 1:43 PM, Stephen Morris wrote:
Thankyou. I issued the command and got the following output but I'm 
not sure what it means.


Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 
'link-mtu' is used inconsistently, local='link-mtu 1558', 
remote='link-mtu 1557'
Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 
'comp-lzo' is present in local config but missing in remote config, 
local='comp-lzo'


You have different options set for the client than the server is 
expecting.


I have now set the mtu to 1557. Previously it wasn't specified at all, 
so presumably it was using whatever Fedora was configured to use.


Also following Ed's suggesting I have turned off lzo compression.



Nov 14 08:34:06 localhost.localdomain nm-openvpn[3877]: Bad LZO 
decompression header byte: 42


Causing this.  They probably can't communicate at all.

Nov 14 08:34:14 localhost.localdomain nm-openvpn[3877]: [VPN] 
Inactivity timeout (--ping-restart), restarting


You seem to have a very short timeout.
These might be a mis-interpretation of things by me. I have ping 
interval set to 10 and ping-restart set to 120, as my interpretation of 
the command in the .ovpn files for each vpn definition I have that I 
downloaded, of    keepalive 10 120   . It is possible I may not have 
understood this keepalive command.


Where did you get your settings from?  Maybe you need to find out what 
the server settings are again and recreate the VPN connection.


Some of the settings I got from .ovpn files specific to the vpn servers 
I am using, and others are carry over's from working configurations from 
networkmanager in F27 where they were default setting supplied with 
creation of the definitions.


Because I haven't tried to use these definitions in a long time (my isp 
won't allow mail communication if I am using one of these vpn's), I 
can't pin-point whether they stopped working with the upgrade to F28, or 
whether they were working in F28 and normal maintenance broke them, or 
whether, since the last time I successfully used the definitions that 
don't work now, the remote server processes have changed.



regards,

Steve



___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 14/11/18 8:56 am, Ed Greshko wrote:

On 11/14/18 5:43 AM, Stephen Morris wrote:

On 14/11/18 4:36 am, Samuel Sieb wrote:

On 11/13/18 3:07 AM, Ed Greshko wrote:

On 11/13/18 12:39 PM, Samuel Sieb wrote:

Run "sudo journalctl -b -t openvpn" to find all the journal entries.

That would actually be

journalctl -b -t nm-openvpn

Thank you.  I've been running the openvpn client directly from the command 
line, so
what I wrote works for me.  But I see it might be different if run from 
NetworkManager.

Thankyou. I issued the command and got the following output but I'm not sure 
what it means.


-- Logs begin at Wed 2016-01-06 07:29:31 AEDT, end at Wed 2018-11-14 08:36:39 
AEDT. --
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: OpenVPN 2.4.6
x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] 
[MH/PKTINFO] [AEAD]
built on Apr >
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: library versions: 
OpenSSL
1.1.0i-fips  14 Aug 2018, LZO 2.08
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: NOTE: the current
--script-security setting may allow this configuration to call user-defined 
scripts
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: TCP/UDP: Preserving 
recently
used remote address: [AF_INET]199.195.193.181:443
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: UDP link local: (not 
bound)
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: UDP link remote:
[AF_INET]199.195.193.181:443
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: NOTE: UID/GID downgrade 
will be
delayed because of --client, --pull, or --up-delay
Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 'link-mtu' is 
used
inconsistently, local='link-mtu 1558', remote='link-mtu 1557'
Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 'comp-lzo' is 
present
in local config but missing in remote config, local='comp-lzo'
Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: [VPN] Peer Connection 
Initiated
with [AF_INET]199.195.193.181:443
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: TUN/TAP device tun0 
opened
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]:
/usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 3872 --bus-name
org.freedesktop.NetworkManager.openvpn.Conn>
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: GID set to nm-openvpn
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: UID set to nm-openvpn
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: Initialization Sequence 
Completed
Nov 14 08:34:06 localhost.localdomain nm-openvpn[3877]: Bad LZO decompression 
header
byte: 42
Nov 14 08:34:14 localhost.localdomain nm-openvpn[3877]: [VPN] Inactivity timeout
(--ping-restart), restarting
Nov 14 08:34:14 localhost.localdomain nm-openvpn[3877]: 
SIGUSR1[soft,ping-restart]
received, process restarting
Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: NOTE: the current
--script-security setting may allow this configuration to call user-defined 
scripts
Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: TCP/UDP: Preserving 
recently
used remote address: [AF_INET]199.195.193.181:443
Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: UDP link local: (not 
bound)
Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: UDP link remote:
[AF_INET]199.195.193.181:443
Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: WARNING: 'link-mtu' is 
used
inconsistently, local='link-mtu 1558', remote='link-mtu 1557'
Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: WARNING: 'comp-lzo' is 
present
in local config but missing in remote config, local='comp-lzo'
Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: [VPN] Peer Connection 
Initiated
with [AF_INET]199.195.193.181:443
Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]: Preserving previous 
TUN/TAP
instance: tun0
Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]:
/usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 3872 --bus-name
org.freedesktop.NetworkManager.openvpn.Conn>
Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]: NOTE: Pulled options 
changed on
restart, will need to close and reopen TUN/TAP device.
Nov 14 08:34:22 localhost.localdomain nm-openvpn[3877]: ERROR: Cannot ioctl 
TUNSETIFF
tun: Operation not permitted (errno=1)



Sorry for not mentioning this before.  But I would actually use

journalctl -b -t nm-dispatcher -t nm-openvpn

Anyway, just looking at the above, I would edit my openvpn connection and under 
"Advanced"
I would set "Use LZO compression to "No" as well as unchecking the box.


Thanks Ed, I have done that. I have also set the mtu to 1557 which the 
server seems to be saying it is expecting.



regards,

Steve







___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: 

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 14/11/18 8:46 am, Ed Greshko wrote:

On 11/14/18 5:32 AM, Stephen Morris wrote:

My hardware clock is running a couple of seconds slow as well.

Just as a matter of curiosity, when you say if you issue hwclock from the bios 
(how have
you done that) what does journalctl show for the same time? Does it show, using 
your
example, 2018-11-12 21:47 or does it show 2018-11-13 21:47?

I did not say what you think I said.

I said, "But if I reboot and go into the BIOS it will show 2018-11-12 21:47", 
which I
thought was clear.

To expound.  I reboot, enter F2 when the Boot (not grub) splash screen comes up 
and enter
the BIOS setup of the motherboard.


I've checked my bios and the bios home screen shows the date and time as 
local time (I also don't remember seeing any functionality on any bios 
screen to change that. I have had motherboards in the past that have 
provided that functionality.).


Going into a terminal shell once KDE had started up and issuing the 
hwclock command I get the following output which is not an issue:


bash-4.4$ sudo hwclock
2018-11-16 07:21:53.014617+11:00

From the same terminal, issuing   journalctl -b 0   I get the following 
messages as the first set of messages it displays. The time at the 
beginning of the messages as to when the system was booted, being 
18:17:18, is correct as GMT time relative to my time zone, which is 
GMT+11 as hwclock shows, but the date of Nov 16 is wrong for GMT, it 
should be Nov 15. The correct GMT time for my time zone relative to when 
I booted is   Nov 15 18:17:18. Hence the question of exactly what is 
that format supposed to be?


When looking at journalctl messages to try to determine why my vpns are 
timing out, where the vpn was started after KDE was active, the time in 
the messages were definitely local time.


bash-4.4$ journalctl -b 0
-- Logs begin at Wed 2016-01-06 07:29:31 AEDT, end at Fri 2018-11-16 
07:22:16 AEDT. --
Nov 16 18:17:18 localhost.localdomain kernel: Linux version 
4.18.14-200.fc28.x86_64 (mockbu...@bkernel03.phx2.fedoraproject.org) 
(gcc version 8.1.1 20180712 (Red Hat 8.1.1-5) (GCC)) #1 SMP Mon Oct >
Nov 16 18:17:18 localhost.localdomain kernel: Command line: 
BOOT_IMAGE=/vmlinuz-4.18.14-200.fc28.x86_64 
root=UUID=8dae94dc-1c3e-4be1-b1f8-b146f094314b ro 
rd.driver.blacklist=nouveau modprobe.blackl>
Nov 16 18:17:18 localhost.localdomain kernel: random: get_random_u32 
called from bsp_init_amd+0x20b/0x2b0 with crng_init=0
Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: Supporting XSAVE 
feature 0x001: 'x87 floating point registers'
Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: Supporting XSAVE 
feature 0x002: 'SSE registers'
Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: Supporting XSAVE 
feature 0x004: 'AVX registers'
Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: 
xstate_offset[2]:  576, xstate_sizes[2]:  256
Nov 16 18:17:18 localhost.localdomain kernel: x86/fpu: Enabled xstate 
features 0x7, context size is 832 bytes, using 'standard' format.
Nov 16 18:17:18 localhost.localdomain kernel: BIOS-provided physical RAM 
map:



regards,

Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 14/11/18 8:46 am, Ed Greshko wrote:

On 11/14/18 5:32 AM, Stephen Morris wrote:

My hardware clock is running a couple of seconds slow as well.

Just as a matter of curiosity, when you say if you issue hwclock from the bios 
(how have
you done that) what does journalctl show for the same time? Does it show, using 
your
example, 2018-11-12 21:47 or does it show 2018-11-13 21:47?

I did not say what you think I said.

I said, "But if I reboot and go into the BIOS it will show 2018-11-12 21:47", 
which I
thought was clear.

To expound.  I reboot, enter F2 when the Boot (not grub) splash screen comes up 
and enter
the BIOS setup of the motherboard.


Sorry Ed, I did misinterpret what you said. I read it as you saying you 
were issuing the hwclock command from the bios.



regards,

Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Samuel Sieb]

On 11/13/18 1:43 PM, Stephen Morris wrote:
Thankyou. I issued the command and got the following output but I'm not 
sure what it means.


Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 
'link-mtu' is used inconsistently, local='link-mtu 1558', 
remote='link-mtu 1557'
Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 
'comp-lzo' is present in local config but missing in remote config, 
local='comp-lzo'


You have different options set for the client than the server is expecting.

Nov 14 08:34:06 localhost.localdomain nm-openvpn[3877]: Bad LZO 
decompression header byte: 42


Causing this.  They probably can't communicate at all.

Nov 14 08:34:14 localhost.localdomain nm-openvpn[3877]: [VPN] Inactivity 
timeout (--ping-restart), restarting


You seem to have a very short timeout.

Where did you get your settings from?  Maybe you need to find out what 
the server settings are again and recreate the VPN connection.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/14/18 5:43 AM, Stephen Morris wrote:
> On 14/11/18 4:36 am, Samuel Sieb wrote:
>> On 11/13/18 3:07 AM, Ed Greshko wrote:
>>> On 11/13/18 12:39 PM, Samuel Sieb wrote:
 Run "sudo journalctl -b -t openvpn" to find all the journal entries.
>>>
>>> That would actually be
>>>
>>> journalctl -b -t nm-openvpn
>>
>> Thank you.  I've been running the openvpn client directly from the command 
>> line, so
>> what I wrote works for me.  But I see it might be different if run from 
>> NetworkManager.
>
> Thankyou. I issued the command and got the following output but I'm not sure 
> what it means.
>
>
> -- Logs begin at Wed 2016-01-06 07:29:31 AEDT, end at Wed 2018-11-14 08:36:39 
> AEDT. --
> Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: OpenVPN 2.4.6
> x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] 
> [MH/PKTINFO] [AEAD]
> built on Apr >
> Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: library versions: 
> OpenSSL
> 1.1.0i-fips  14 Aug 2018, LZO 2.08
> Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: NOTE: the current
> --script-security setting may allow this configuration to call user-defined 
> scripts
> Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: TCP/UDP: Preserving 
> recently
> used remote address: [AF_INET]199.195.193.181:443
> Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: UDP link local: (not 
> bound)
> Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: UDP link remote:
> [AF_INET]199.195.193.181:443
> Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: NOTE: UID/GID 
> downgrade will be
> delayed because of --client, --pull, or --up-delay
> Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 'link-mtu' 
> is used
> inconsistently, local='link-mtu 1558', remote='link-mtu 1557'
> Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 'comp-lzo' 
> is present
> in local config but missing in remote config, local='comp-lzo'
> Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: [VPN] Peer Connection 
> Initiated
> with [AF_INET]199.195.193.181:443
> Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: TUN/TAP device tun0 
> opened
> Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]:
> /usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 3872 --bus-name
> org.freedesktop.NetworkManager.openvpn.Conn>
> Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: GID set to nm-openvpn
> Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: UID set to nm-openvpn
> Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: Initialization 
> Sequence Completed
> Nov 14 08:34:06 localhost.localdomain nm-openvpn[3877]: Bad LZO decompression 
> header
> byte: 42
> Nov 14 08:34:14 localhost.localdomain nm-openvpn[3877]: [VPN] Inactivity 
> timeout
> (--ping-restart), restarting
> Nov 14 08:34:14 localhost.localdomain nm-openvpn[3877]: 
> SIGUSR1[soft,ping-restart]
> received, process restarting
> Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: NOTE: the current
> --script-security setting may allow this configuration to call user-defined 
> scripts
> Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: TCP/UDP: Preserving 
> recently
> used remote address: [AF_INET]199.195.193.181:443
> Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: UDP link local: (not 
> bound)
> Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: UDP link remote:
> [AF_INET]199.195.193.181:443
> Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: WARNING: 'link-mtu' 
> is used
> inconsistently, local='link-mtu 1558', remote='link-mtu 1557'
> Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: WARNING: 'comp-lzo' 
> is present
> in local config but missing in remote config, local='comp-lzo'
> Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: [VPN] Peer Connection 
> Initiated
> with [AF_INET]199.195.193.181:443
> Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]: Preserving previous 
> TUN/TAP
> instance: tun0
> Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]:
> /usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 3872 --bus-name
> org.freedesktop.NetworkManager.openvpn.Conn>
> Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]: NOTE: Pulled options 
> changed on
> restart, will need to close and reopen TUN/TAP device.
> Nov 14 08:34:22 localhost.localdomain nm-openvpn[3877]: ERROR: Cannot ioctl 
> TUNSETIFF
> tun: Operation not permitted (errno=1)
>
>

Sorry for not mentioning this before.  But I would actually use

journalctl -b -t nm-dispatcher -t nm-openvpn

Anyway, just looking at the above, I would edit my openvpn connection and under 
"Advanced"
I would set "Use LZO compression to "No" as well as unchecking the box.



-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of 

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/14/18 5:32 AM, Stephen Morris wrote:
> My hardware clock is running a couple of seconds slow as well.
>
> Just as a matter of curiosity, when you say if you issue hwclock from the 
> bios (how have
> you done that) what does journalctl show for the same time? Does it show, 
> using your
> example, 2018-11-12 21:47 or does it show 2018-11-13 21:47? 

I did not say what you think I said.

I said, "But if I reboot and go into the BIOS it will show 2018-11-12 21:47", 
which I
thought was clear.

To expound.  I reboot, enter F2 when the Boot (not grub) splash screen comes up 
and enter
the BIOS setup of the motherboard.

-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 14/11/18 4:36 am, Samuel Sieb wrote:

On 11/13/18 3:07 AM, Ed Greshko wrote:

On 11/13/18 12:39 PM, Samuel Sieb wrote:

Run "sudo journalctl -b -t openvpn" to find all the journal entries.


That would actually be

journalctl -b -t nm-openvpn


Thank you.  I've been running the openvpn client directly from the 
command line, so what I wrote works for me.  But I see it might be 
different if run from NetworkManager.


Thankyou. I issued the command and got the following output but I'm not 
sure what it means.



-- Logs begin at Wed 2016-01-06 07:29:31 AEDT, end at Wed 2018-11-14 
08:36:39 AEDT. --
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: OpenVPN 2.4.6 
x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] 
[MH/PKTINFO] [AEAD] built on Apr >
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: library 
versions: OpenSSL 1.1.0i-fips  14 Aug 2018, LZO 2.08
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: NOTE: the 
current --script-security setting may allow this configuration to call 
user-defined scripts
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: TCP/UDP: 
Preserving recently used remote address: [AF_INET]199.195.193.181:443
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: UDP link local: 
(not bound)
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: UDP link remote: 
[AF_INET]199.195.193.181:443
Nov 14 08:33:42 localhost.localdomain nm-openvpn[3877]: NOTE: UID/GID 
downgrade will be delayed because of --client, --pull, or --up-delay
Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 
'link-mtu' is used inconsistently, local='link-mtu 1558', 
remote='link-mtu 1557'
Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: WARNING: 
'comp-lzo' is present in local config but missing in remote config, 
local='comp-lzo'
Nov 14 08:33:43 localhost.localdomain nm-openvpn[3877]: [VPN] Peer 
Connection Initiated with [AF_INET]199.195.193.181:443
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: TUN/TAP device 
tun0 opened
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: 
/usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 3872 --bus-name 
org.freedesktop.NetworkManager.openvpn.Conn>
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: GID set to 
nm-openvpn
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: UID set to 
nm-openvpn
Nov 14 08:33:44 localhost.localdomain nm-openvpn[3877]: Initialization 
Sequence Completed
Nov 14 08:34:06 localhost.localdomain nm-openvpn[3877]: Bad LZO 
decompression header byte: 42
Nov 14 08:34:14 localhost.localdomain nm-openvpn[3877]: [VPN] Inactivity 
timeout (--ping-restart), restarting
Nov 14 08:34:14 localhost.localdomain nm-openvpn[3877]: 
SIGUSR1[soft,ping-restart] received, process restarting
Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: NOTE: the 
current --script-security setting may allow this configuration to call 
user-defined scripts
Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: TCP/UDP: 
Preserving recently used remote address: [AF_INET]199.195.193.181:443
Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: UDP link local: 
(not bound)
Nov 14 08:34:19 localhost.localdomain nm-openvpn[3877]: UDP link remote: 
[AF_INET]199.195.193.181:443
Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: WARNING: 
'link-mtu' is used inconsistently, local='link-mtu 1558', 
remote='link-mtu 1557'
Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: WARNING: 
'comp-lzo' is present in local config but missing in remote config, 
local='comp-lzo'
Nov 14 08:34:20 localhost.localdomain nm-openvpn[3877]: [VPN] Peer 
Connection Initiated with [AF_INET]199.195.193.181:443
Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]: Preserving 
previous TUN/TAP instance: tun0
Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]: 
/usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 3872 --bus-name 
org.freedesktop.NetworkManager.openvpn.Conn>
Nov 14 08:34:21 localhost.localdomain nm-openvpn[3877]: NOTE: Pulled 
options changed on restart, will need to close and reopen TUN/TAP device.
Nov 14 08:34:22 localhost.localdomain nm-openvpn[3877]: ERROR: Cannot 
ioctl TUNSETIFF tun: Operation not permitted (errno=1)



regards,

Steve



___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 13/11/18 8:52 am, Ed Greshko wrote:

On 11/13/18 4:49 AM, Stephen Morris wrote:

So given all this, when searching journalctl for boot messages across particular
datetime ranges, how do you find them when the timestamps in
the journals are blatantly wrong, potentially up until the desktop loads?

I don't know.  I've not had this sort of problem since years ago when my HW 
clock was not
set to GMT/UTC.

FWIW,

[root@meimei ~]# date ; hwclock ; uptime
Tue Nov 13 05:47:36 CST 2018
2018-11-13 05:47:28.405437+08:00
  05:47:36 up 3 days

So, you can see my HW clock is running a bit slow.

The hwclock command always shows time as local.  (see the man page)  But if I 
reboot and
go into the BIOS
it will show 2018-11-12 21:47...


My hardware clock is running a couple of seconds slow as well.

Just as a matter of curiosity, when you say if you issue hwclock from 
the bios (how have you done that) what does journalctl show for the same 
time? Does it show, using your example, 2018-11-12 21:47 or does it show 
2018-11-13 21:47?



regards,

Steve







___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Samuel Sieb]

On 11/13/18 3:07 AM, Ed Greshko wrote:

On 11/13/18 12:39 PM, Samuel Sieb wrote:

Run "sudo journalctl -b -t openvpn" to find all the journal entries.


That would actually be

journalctl -b -t nm-openvpn


Thank you.  I've been running the openvpn client directly from the 
command line, so what I wrote works for me.  But I see it might be 
different if run from NetworkManager.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/13/18 12:39 PM, Samuel Sieb wrote:
> On 11/6/18 1:43 PM, Stephen Morris wrote:
>>  When I start one of the two vpn definitions, that have been in 
>> networkmanager for
>> years and used to work fine (I haven't used them in quite a while), it 
>> starts and I get
>> a pop-up message saying that interface tun0 has been activated in the 
>> firewall default
>> zone (being fedoraworkstation). This interface remains active for about a 
>> minute or so
>> until I get the pop-up message that interface tun0 has been deactivated in 
>> the firewall
>> default zone, and the vpn is no longer connected. The vpn connection is 
>> using Openvpn.
>>
>>  I have checked dmesg for any message relative to tun0 or firewall and 
>> there are no
>> messages for either. How do I determine why the vpn won't stay active?
>
> Run "sudo journalctl -b -t openvpn" to find all the journal entries.

That would actually be

journalctl -b -t nm-openvpn

-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Patrick O'Callaghan]

On Mon, 2018-11-12 at 20:39 -0800, Samuel Sieb wrote:
> On 11/6/18 1:43 PM, Stephen Morris wrote:
> >  When I start one of the two vpn definitions, that have been in 
> > networkmanager for years and used to work fine (I haven't used them in 
> > quite a while), it starts and I get a pop-up message saying that 
> > interface tun0 has been activated in the firewall default zone (being 
> > fedoraworkstation). This interface remains active for about a minute or 
> > so until I get the pop-up message that interface tun0 has been 
> > deactivated in the firewall default zone, and the vpn is no longer 
> > connected. The vpn connection is using Openvpn.
> > 
> >  I have checked dmesg for any message relative to tun0 or firewall 
> > and there are no messages for either. How do I determine why the vpn 
> > won't stay active?
> 
> Run "sudo journalctl -b -t openvpn" to find all the journal entries.

Slightly OT, but '-t' requires a SYSLOG_IDENTIFIER as argument. However
the man page for journalctl doesn't specify what that means. It's
clearly not just a substring (you can get that with '-g') so what
exactly is it?

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Samuel Sieb]

On 11/6/18 1:43 PM, Stephen Morris wrote:
     When I start one of the two vpn definitions, that have been in 
networkmanager for years and used to work fine (I haven't used them in 
quite a while), it starts and I get a pop-up message saying that 
interface tun0 has been activated in the firewall default zone (being 
fedoraworkstation). This interface remains active for about a minute or 
so until I get the pop-up message that interface tun0 has been 
deactivated in the firewall default zone, and the vpn is no longer 
connected. The vpn connection is using Openvpn.


     I have checked dmesg for any message relative to tun0 or firewall 
and there are no messages for either. How do I determine why the vpn 
won't stay active?


Run "sudo journalctl -b -t openvpn" to find all the journal entries.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/13/18 4:49 AM, Stephen Morris wrote:
> So given all this, when searching journalctl for boot messages across 
> particular
> datetime ranges, how do you find them when the timestamps in
> the journals are blatantly wrong, potentially up until the desktop loads?

I don't know.  I've not had this sort of problem since years ago when my HW 
clock was not
set to GMT/UTC.

FWIW,

[root@meimei ~]# date ; hwclock ; uptime
Tue Nov 13 05:47:36 CST 2018
2018-11-13 05:47:28.405437+08:00
 05:47:36 up 3 days

So, you can see my HW clock is running a bit slow.

The hwclock command always shows time as local.  (see the man page)  But if I 
reboot and
go into the BIOS
it will show 2018-11-12 21:47...



-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/12/18 12:49 PM, Stephen Morris wrote:
> On 9/11/18 8:28 pm, Patrick O'Callaghan wrote:
>> On Fri, 2018-11-09 at 00:08 +, Rick Stevens wrote:
>>> On 11/8/18 2:41 PM, Patrick O'Callaghan wrote:
 On Fri, 2018-11-09 at 08:02 +1100, Stephen Morris wrote:
> how is linux using GMT when everything is running local.
 All Unix-based or Unix-derived systems, including Linux, use GMT
 internally, and have done since the very first versions back in the
 70s.
>>> Uhm, they _assume_ GMT on the hardware clock. There is no way for the
>>> kernel to verify it's on GMT if it's isolated.
>> Of course. That's what I mean. The GMT basis for all time measurement
>> in *nix is hardwired.
>>
>>> NTP (chronyd, ntpd,
>>> ntpdate, whatever) will force the clock to GMT, but if you don't run
>>> NTP I can see very weird stuff on file dates and logs because the
>>> kernel will assume GMT on the system and translate it to local time.
>>>
 Even if you set your hardware clock to local time, the internal
 timestamps used for files will be stored as GMT and converted back when
 displayed, according to your timezone environment. This also applies to
 logs.
>>> Which would explain any mondo weird timestamps in his log. I believe the
>>> OP said there was a significant time jump in the log entries at some
>>> point. I could see this if his clock isn't on GMT and was drug there
>>> kicking and screaming by NTP. Logs produced before NTP got caught up
>>> would assume the old, local hardware clock time (and be way off), then
>>> the clock gets buggered by NTP and the log entries start making sense
>>> from that point.
>>>
>>> This is all surmise on my part, of course.
>> Yes, there is probably some interaction of that sort going on.
> 
> So given all this, when searching journalctl for boot messages across
> particular datetime ranges, how do you find them when the timestamps in
> the journals are blatantly wrong, potentially up until the desktop loads?

I don't believe it's when the desktop loads that changes the clock, but
when chronyd resets it. But that doesn't help you much.

I don't know what to tell you. You're trying to base a search on data
that is inconsistent. My guess is you'd need to do two searches, one for
the time the clock gets caught up, then adjust your next search to
whether you think the event was before or after that time. For example:

[root@prophead ~]# journalctl -b -u chronyd
-- Logs begin at Thu 2016-06-23 10:06:25 PDT, end at Mon 2018-11-12
13:27:11 PST. --
Oct 22 09:39:45 prophead.alldigital.net systemd[1]: Starting NTP
client/server...
Oct 22 09:39:46 prophead.alldigital.net chronyd[1062]: chronyd version
3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVD>
Oct 22 09:39:46 prophead.alldigital.net chronyd[1062]: Frequency 13.721
+/- 0.032 ppm read from /var/lib/chrony/drift
Oct 22 09:39:53 prophead.alldigital.net systemd[1]: Started NTP
client/server.
Oct 22 09:40:44 prophead.alldigital.net chronyd[1062]: Selected source
(redacted)
Oct 22 09:40:44 prophead.alldigital.net chronyd[1062]: System clock
wrong by 29.498546 seconds, adjustment started
Oct 22 09:41:13 prophead.alldigital.net chronyd[1062]: System clock was
stepped by 29.498546 seconds

You can see there that the journal was plugging along, then at 9:40:44
the system noticed the clock was about 30 seconds slow, so it poked it
and the clock entries changed from 09:40:44 to 09:41:13, just about 29
seconds forward. So, prior to 09:40:44, I'd use that as my search
and after that point, things should be synced to the real time.

Not much help, but...
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
- Blessed be the peacekeepers, for they shall be shot at from-
-both sides. -
--- A.M. Greeley -
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 9/11/18 8:28 pm, Patrick O'Callaghan wrote:

On Fri, 2018-11-09 at 00:08 +, Rick Stevens wrote:

On 11/8/18 2:41 PM, Patrick O'Callaghan wrote:

On Fri, 2018-11-09 at 08:02 +1100, Stephen Morris wrote:

how is linux using GMT when everything is running local.

All Unix-based or Unix-derived systems, including Linux, use GMT
internally, and have done since the very first versions back in the
70s.

Uhm, they _assume_ GMT on the hardware clock. There is no way for the
kernel to verify it's on GMT if it's isolated.

Of course. That's what I mean. The GMT basis for all time measurement
in *nix is hardwired.


NTP (chronyd, ntpd,
ntpdate, whatever) will force the clock to GMT, but if you don't run
NTP I can see very weird stuff on file dates and logs because the
kernel will assume GMT on the system and translate it to local time.


Even if you set your hardware clock to local time, the internal
timestamps used for files will be stored as GMT and converted back when
displayed, according to your timezone environment. This also applies to
logs.

Which would explain any mondo weird timestamps in his log. I believe the
OP said there was a significant time jump in the log entries at some
point. I could see this if his clock isn't on GMT and was drug there
kicking and screaming by NTP. Logs produced before NTP got caught up
would assume the old, local hardware clock time (and be way off), then
the clock gets buggered by NTP and the log entries start making sense
from that point.

This is all surmise on my part, of course.

Yes, there is probably some interaction of that sort going on.


So given all this, when searching journalctl for boot messages across 
particular datetime ranges, how do you find them when the timestamps in 
the journals are blatantly wrong, potentially up until the desktop loads?



regards,

Steve




poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Patrick O'Callaghan]

On Fri, 2018-11-09 at 00:08 +, Rick Stevens wrote:
> On 11/8/18 2:41 PM, Patrick O'Callaghan wrote:
> > On Fri, 2018-11-09 at 08:02 +1100, Stephen Morris wrote:
> > > how is linux using GMT when everything is running local.
> > 
> > All Unix-based or Unix-derived systems, including Linux, use GMT
> > internally, and have done since the very first versions back in the
> > 70s.
> 
> Uhm, they _assume_ GMT on the hardware clock. There is no way for the
> kernel to verify it's on GMT if it's isolated.

Of course. That's what I mean. The GMT basis for all time measurement
in *nix is hardwired.

> NTP (chronyd, ntpd,
> ntpdate, whatever) will force the clock to GMT, but if you don't run
> NTP I can see very weird stuff on file dates and logs because the
> kernel will assume GMT on the system and translate it to local time.
> 
> > Even if you set your hardware clock to local time, the internal
> > timestamps used for files will be stored as GMT and converted back when
> > displayed, according to your timezone environment. This also applies to
> > logs.
> 
> Which would explain any mondo weird timestamps in his log. I believe the
> OP said there was a significant time jump in the log entries at some
> point. I could see this if his clock isn't on GMT and was drug there
> kicking and screaming by NTP. Logs produced before NTP got caught up
> would assume the old, local hardware clock time (and be way off), then
> the clock gets buggered by NTP and the log entries start making sense
> from that point.
> 
> This is all surmise on my part, of course.

Yes, there is probably some interaction of that sort going on.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/8/18 2:41 PM, Patrick O'Callaghan wrote:
> On Fri, 2018-11-09 at 08:02 +1100, Stephen Morris wrote:
>> how is linux using GMT when everything is running local.
> 
> All Unix-based or Unix-derived systems, including Linux, use GMT
> internally, and have done since the very first versions back in the
> 70s.

Uhm, they _assume_ GMT on the hardware clock. There is no way for the
kernel to verify it's on GMT if it's isolated. NTP (chronyd, ntpd,
ntpdate, whatever) will force the clock to GMT, but if you don't run
NTP I can see very weird stuff on file dates and logs because the
kernel will assume GMT on the system and translate it to local time.

> Even if you set your hardware clock to local time, the internal
> timestamps used for files will be stored as GMT and converted back when
> displayed, according to your timezone environment. This also applies to
> logs.

Which would explain any mondo weird timestamps in his log. I believe the
OP said there was a significant time jump in the log entries at some
point. I could see this if his clock isn't on GMT and was drug there
kicking and screaming by NTP. Logs produced before NTP got caught up
would assume the old, local hardware clock time (and be way off), then
the clock gets buggered by NTP and the log entries start making sense
from that point.

This is all surmise on my part, of course.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Patrick O'Callaghan]

On Fri, 2018-11-09 at 08:02 +1100, Stephen Morris wrote:
> how is linux using GMT when everything is running local.

All Unix-based or Unix-derived systems, including Linux, use GMT
internally, and have done since the very first versions back in the
70s. Even if you set your hardware clock to local time, the internal
timestamps used for files will be stored as GMT and converted back when
displayed, according to your timezone environment. This also applies to
logs.

poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 8/11/18 11:00 pm, Ed Greshko wrote:

On 11/8/18 8:29 AM, Rick Stevens wrote:

A lot of the timezones are symlinked to Etc/UTC and it's listed as
"canonical", so perhaps we're both right. Nyaah! Tht! :-P

I can live with that.  :-)

I'm confused. If I have my linux desktops configured to display local 
time instead of GMT (or at least I used to in versions of Fedora prior 
to F28, I haven't checked if upgrades have continued to maintain that 
setting) and have the bios in my motherboard set to operate on local 
time, how is linux using GMT when everything is running local. I run 
things this way because I tri-boot between Fedora 28, Ubuntu and Windows 10.


Irrespective of the above, if journalctl -b 0 displayed the "journals" 
for the current boot session, the timestamps shown on those messages are 
wrong if they are GMT. With the timezone I am in, now that we are on 
daylight savings time, we are 11 hours ahead of GMT. As I booted the 
system on Nov 08 at 07:16, GMT time is Nov 07 18:16 not Nov 08 18:16 as 
displayed by journalctl. If the timestamps on the messages relative to 
the boot processing before the desktop get loaded, are not GMT but a 
combination of local date and GMT time, that can lead to all sorts of 
confusion as to when the messages are really for.



regards,

Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/8/18 8:29 AM, Rick Stevens wrote:
> A lot of the timezones are symlinked to Etc/UTC and it's listed as
> "canonical", so perhaps we're both right. Nyaah! Tht! :-P

I can live with that.  :-)

-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/7/18 4:14 PM, Ed Greshko wrote:
> On 11/8/18 7:55 AM, Rick Stevens wrote:
>> Yes, HW clock set to GMT (well, technically UTC) for Linux is standard.
>> The local time is computed based on your timezone. I have the HW clock
>> set to UTC on all my machines and I see the correct local time in my
>> logs.
> 
> Well, we were talking about "time zones" I'm pretty sure GMT is preferred.  
> Remember GMT
> is a "time zone" while UTC is a standard.  :-)

Well, yeah. But I'm a pilot and we always use UTC. My systems are set to
UTC. A lot of the timezones are symlinked to Etc/UTC and it's listed as
"canonical", so perhaps we're both right. Nyaah! Tht! :-p

>> A UTC hardware clock will confuse the hell out of Windows. If you dual-
>> boot Windows and Linux, this will cause some head scratches.
> 
> So I've heard.  :-)
Odd, too, since WinNT (the archetype for Windows 7/8/10) was essentially
written by the same blokes who wrote VAX/VMS for DEC and (IIRC) VAX/VMS
preferred GMT for clocks. It's been a LONG time since I futzed with it
but that's what I recall. I could be wrong (and probably am).
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
-   Blessed are the peacekeepers...for they shall be shot at -
- from both sides. --A.M. Greeley-
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/8/18 7:55 AM, Rick Stevens wrote:
> Yes, HW clock set to GMT (well, technically UTC) for Linux is standard.
> The local time is computed based on your timezone. I have the HW clock
> set to UTC on all my machines and I see the correct local time in my
> logs.

Well, we were talking about "time zones" I'm pretty sure GMT is preferred.  
Remember GMT
is a "time zone" while UTC is a standard.  :-)

>
> A UTC hardware clock will confuse the hell out of Windows. If you dual-
> boot Windows and Linux, this will cause some head scratches.

So I've heard.  :-)

-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Rick Stevens]

On 11/7/18 2:36 PM, Ed Greshko wrote:
> On 11/8/18 5:31 AM, Stephen Morris wrote:
>> Thanks Ed, I issued that command and fed the output into grep to search for 
>> tun0, and
>> found messages saying that the device was successfully activated, and then 
>> about 30
>> seconds later a message saying the connection timed out, and then almost a 
>> further 30
>> seconds for the connection to actually shutdown. I'll have to contact the 
>> vendor to see
>> if the 10 year renewal period on my lifetime membership has been reached.
> 
> Well, in order to examine the totality of the session it would note the time 
> (I put a
> digital clock widget on screen) the VPN was activated and the time it 
> disconnected.  I
> would then use the --since and --until parameters to  extract the info.
> 
> I just started and then stopped a connection and used
> 
> journalctl -b 0 --since 06:19:00 --until 06:19:25  >  session
> 
> So, I can see the whole process.  FWIW, I manually disconnected at 06:19:15.
> 
>>
>>
>> Just one question on the journalctl output, when I issued journalctl -b 0, 
>> the messages
>> displayed had the correct day timestamp but the time displayed in GMT time 
>> (with today
>> being Nov 08 and the machine being booted at 07:16, the messages displayed 
>> by journalctl
>> were timestamped Nov 08 18:16, if this time really is GMT time it should 
>> have been Nov
>> 07 18:16), but when I issued the command journalctl -b 0 | grep -i tun0 the 
>> messages
>> displayed were correctly timestamped with the current date and local time. 
>> Is there
>> really two different time formats in use or is there something else at play, 
>> like at
>> initial boot time the system is running on GMT time and then at a later 
>> point in the
>> boot process or when KDE starts the system is running in local time? If it 
>> is the case
>> the next question then becomes why is the day wrong in the GMT 
>> representation.
>>
> 
> I have never seen that behavior.  But, I have my HW clock set to GMT.  I seem 
> to recall
> this to be the preferred setting and you may have issues with time stamps if 
> set otherwise.

Yes, HW clock set to GMT (well, technically UTC) for Linux is standard.
The local time is computed based on your timezone. I have the HW clock
set to UTC on all my machines and I see the correct local time in my
logs.

A UTC hardware clock will confuse the hell out of Windows. If you dual-
boot Windows and Linux, this will cause some head scratches.
--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 226437340   Yahoo: origrps2 -
--
- The trouble with troubleshooting is that trouble sometimes -
- shoots back.   -
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/8/18 5:31 AM, Stephen Morris wrote:
> Thanks Ed, I issued that command and fed the output into grep to search for 
> tun0, and
> found messages saying that the device was successfully activated, and then 
> about 30
> seconds later a message saying the connection timed out, and then almost a 
> further 30
> seconds for the connection to actually shutdown. I'll have to contact the 
> vendor to see
> if the 10 year renewal period on my lifetime membership has been reached.

Well, in order to examine the totality of the session it would note the time (I 
put a
digital clock widget on screen) the VPN was activated and the time it 
disconnected.  I
would then use the --since and --until parameters to  extract the info.

I just started and then stopped a connection and used

journalctl -b 0 --since 06:19:00 --until 06:19:25  >  session

So, I can see the whole process.  FWIW, I manually disconnected at 06:19:15.

>
>
> Just one question on the journalctl output, when I issued journalctl -b 0, 
> the messages
> displayed had the correct day timestamp but the time displayed in GMT time 
> (with today
> being Nov 08 and the machine being booted at 07:16, the messages displayed by 
> journalctl
> were timestamped Nov 08 18:16, if this time really is GMT time it should have 
> been Nov
> 07 18:16), but when I issued the command journalctl -b 0 | grep -i tun0 the 
> messages
> displayed were correctly timestamped with the current date and local time. Is 
> there
> really two different time formats in use or is there something else at play, 
> like at
> initial boot time the system is running on GMT time and then at a later point 
> in the
> boot process or when KDE starts the system is running in local time? If it is 
> the case
> the next question then becomes why is the day wrong in the GMT representation.
>

I have never seen that behavior.  But, I have my HW clock set to GMT.  I seem 
to recall
this to be the preferred setting and you may have issues with time stamps if 
set otherwise.


-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Stephen Morris]

On 7/11/18 10:17 am, Ed Greshko wrote:

On 11/7/18 5:43 AM, Stephen Morris wrote:

     When I start one of the two vpn definitions, that have been in 
networkmanager for
years and used to work fine (I haven't used them in quite a while), it starts 
and I get
a pop-up message saying that interface tun0 has been activated in the firewall 
default
zone (being fedoraworkstation). This interface remains active for about a 
minute or so
until I get the pop-up message that interface tun0 has been deactivated in the 
firewall
default zone, and the vpn is no longer connected. The vpn connection is using 
Openvpn.

     I have checked dmesg for any message relative to tun0 or firewall and 
there are no
messages for either. How do I determine why the vpn won't stay active?

Messages about Network status are in the journal.  Use journalctl to 
investigate.  I'd use
the -b 0 parameter to limit the output to the current boot.

Thanks Ed, I issued that command and fed the output into grep to search 
for tun0, and found messages saying that the device was successfully 
activated, and then about 30 seconds later a message saying the 
connection timed out, and then almost a further 30 seconds for the 
connection to actually shutdown. I'll have to contact the vendor to see 
if the 10 year renewal period on my lifetime membership has been reached.



Just one question on the journalctl output, when I issued journalctl -b 
0, the messages displayed had the correct day timestamp but the time 
displayed in GMT time (with today being Nov 08 and the machine being 
booted at 07:16, the messages displayed by journalctl were timestamped 
Nov 08 18:16, if this time really is GMT time it should have been Nov 07 
18:16), but when I issued the command journalctl -b 0 | grep -i tun0 the 
messages displayed were correctly timestamped with the current date and 
local time. Is there really two different time formats in use or is 
there something else at play, like at initial boot time the system is 
running on GMT time and then at a later point in the boot process or 
when KDE starts the system is running in local time? If it is the case 
the next question then becomes why is the day wrong in the GMT 
representation.



regards,

Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: VPN Interface not Remaining Active With Firewall?

[Ed Greshko]

On 11/7/18 5:43 AM, Stephen Morris wrote:
>     When I start one of the two vpn definitions, that have been in 
> networkmanager for
> years and used to work fine (I haven't used them in quite a while), it starts 
> and I get
> a pop-up message saying that interface tun0 has been activated in the 
> firewall default
> zone (being fedoraworkstation). This interface remains active for about a 
> minute or so
> until I get the pop-up message that interface tun0 has been deactivated in 
> the firewall
> default zone, and the vpn is no longer connected. The vpn connection is using 
> Openvpn.
>
>     I have checked dmesg for any message relative to tun0 or firewall and 
> there are no
> messages for either. How do I determine why the vpn won't stay active? 

Messages about Network status are in the journal.  Use journalctl to 
investigate.  I'd use
the -b 0 parameter to limit the output to the current boot.

-- 
Fedora Users - The place to go to beat OT dead horses :-) :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org