Re: debian forgot usr pw

[Max Nikulin]

On 08/12/2023 08:49, gene heskett wrote:
I've now set a root pw, about 34 chars, so they'll be a couple eons 
guessing it AND (horrors) have written it down.


Consider pass phrases.


Deep Dive: EFF's New Wordlists for Random Passphrases
By Joseph Bonneau July 19, 2016

is declared to be an improvement of diceware.

kepassxc supports generation of pass phrases based on the EFF word list. 
A couple of memorable pass phrases (for different scopes) may protect 
other passwords stored in a password manager.


https://xkcd.com/936/ Password Strength

To anyone who understands information theory and security and is in an
infuriating argument with someone who does not (possibly involving mixed
case), I sincerely apologize.

Re: debian forgot usr pw

[John Hasler]

Gene writes:
> AND (horrors) have written it down.

That's the right thing to do.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: debian forgot usr pw

[John Hasler]

Greg writes:
> And you should either *use* it once in a while, so you don't forget
> what it is, or else make it the same as your regular account's
> password.

Write the damn thing down.  The world won't end.
-- 
John "Write all your passwords down. It isn't 1980 anymore." Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Local time in databases (Re: ntpsec as server questions)

[tomas]

On Thu, Dec 07, 2023 at 10:18:44PM -0600, Nicholas Geovanis wrote:

[...]

> All of these considerations are what brought Oracle to create a proprietary
> "datetime" datatype and use it to store all "real" dates/times. If you need
> a different format for display purposes or a human readable column, you can
> extract it and do that. But the internal  representation will be driven by
> other needs.
> YMMV :-)

If anyone is looking for inspiration, I think what PostgreSQL does is one of
the best and most complete implementations I've seen.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Local time in databases (Re: ntpsec as server questions)

[tomas]

On Fri, Dec 08, 2023 at 09:11:12AM +0700, Max Nikulin wrote:
> On 07/12/2023 23:08, tomas wrote:
> > On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:
> > > On 07/12/2023 21:22, John Hasler wrote:
> > > > Databases should never store local time.
> > > 
> > > There are exceptions when storing UTC instead of local time leads to
> > > undesired consequences.
> > 
> > Heh. There was one huge thread in Emacs user about a year ago (don't
> > ask me in which time zone).
> 
> Perhaps you mean emacs-ormode.

Right, that was it. I envy your memory :-)

> Then an important difference arises.
> Timestamp are stored not in a database, but in a plain text file and must be
> human readable, moreover some users prefer to type timestamps directly
> without dedicated commands.

The difference is there, but basically, it's minor.

> Leaving aside future timestamps that may need local time, significant
> fraction of timestamps may be reliably represented in UTC. I still have no
> clue why some people were strongly against local time with explicit time
> offset "2023-12-07 17:08:50 +0100". From my point of view such format may be
> unambiguously mapped to UTC "2023-12-07T16:08:50Z" and more convenient for
> users residing in Europe/Berlin. There were participants insisting on either
> forcing UTC or using IANA identifiers "2023-12-07 17:08:50 Europe/Berlin".
> The latter format has issues close to backward DST time shifts and should be
> augmented with disambiguation hints.

100% agreement. Perhaps *both* is best: the time zone (to keep "intention")
and the offset (to keep "actual time"). If I could go backwards in time
(heh ;-), that's what I would have talked that customer into.

[...]

> Local time is widely used in logs. The question is if the client can accept
> ambiguity

This was an industrial application logging measurements from machines all
over the place (and to different log files), so if a shed went up in flames,
you'd be comparing different logs to each other to try to find out what
went wrong.

So no, IMO not in that case. It took me days of talking :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: ntpsec as server questions

[gene heskett]

On 12/7/23 22:08, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 09:38:43AM +0700, Max Nikulin wrote:

- IANA TZ DB does not support timezones disappeared before 1970.
   


Ohhh, *this* is the kind of reference I've been looking for.

So, we simply acknowledge that historical clock information prior to 1970
is just not feasibly discoverable.  All of the time zone choices are
going to be flawed, for almost all of the people in the world.  We just
pick from the ones that are known to be good enough.

.
Of minor interest to me, not once in the above link does it credit the 
K&R Manual for C, which has a method for determining leap years. It was 
also used in some astronomical programs for lunar and solar eclipses. 
This I think was the reason that all unix times start at midnight 
1/1/1970. In the FWIW dept this time formula is pretty accurate back to 
the middle of 4713 BC.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Local time in databases (Re: ntpsec as server questions)

[Nicholas Geovanis]

On Thu, Dec 7, 2023, 8:11 PM Max Nikulin  wrote:

> On 07/12/2023 23:08, tomas wrote:
> > On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:
> >> On 07/12/2023 21:22, John Hasler wrote:
> >>> Databases should never store local time.
> >>
> >> There are exceptions when storing UTC instead of local time leads to
> >> undesired consequences.
> >
> > Heh. There was one huge thread in Emacs user about a year ago (don't
> > ask me in which time zone).
>
> Perhaps you mean emacs-ormode.
>


> Leaving aside future timestamps that may need local time, significant
> fraction of timestamps may be reliably represented in UTC.
>


> As I said above I see nothing wrong in local time with explicit time
> offset. Mail has been using it for decades:
> > Date: Thu, 7 Dec 2023 17:08:50 +0100
>

All of these considerations are what brought Oracle to create a proprietary
"datetime" datatype and use it to store all "real" dates/times. If you need
a different format for display purposes or a human readable column, you can
extract it and do that. But the internal  representation will be driven by
other needs.
YMMV :-)

Re: ntpsec as server questions

[Greg Wooledge]

On Fri, Dec 08, 2023 at 09:38:43AM +0700, Max Nikulin wrote:
> - IANA TZ DB does not support timezones disappeared before 1970.
>   

Ohhh, *this* is the kind of reference I've been looking for.

So, we simply acknowledge that historical clock information prior to 1970
is just not feasibly discoverable.  All of the time zone choices are
going to be flawed, for almost all of the people in the world.  We just
pick from the ones that are known to be good enough.

Re: ntpsec as server questions

[Max Nikulin]

On 07/12/2023 06:11, Pocket wrote:


Because DST was not in force/usage except the metro NYC. Every where 
else didn't use/have it.


That makes EST5DST correct except for NYC and America/New_York 
completely incorrect except of course NYC.


Which is why I prefer to use EST5DST


It may be a valid reason, however
- You stated that you do not care concerning historical timestamps.
- It is still unclear for me for what territory EST5EDT is more correct 
than America/New_York or another similar timezone. My expectation is 
that America/New_York is accurate at least for New York and 
America/Detroit is accurate for Detroit.

- EST5EDT in Debian is extension in respect to POSIX.
- America/New_York and EST2EDT are both provided by the same tzdata 
package, so quality of America/New_York is not worse.

- IANA TZ DB does not support timezones disappeared before 1970.
  
- After 1970 these timezones have no discrepancy.

BTW there isn't any timezone called America/New_York, it is or course 
the Eastern Standard Time Zone.


America/New_your should actually be called America/Eastern.  The POSIX 
EST5DST is closer to being correct.


For me America/New_York is just an identifier. Perhaps you do not like 
this city for some reason, but for me it has no negative context. 
Decisions related to identifiers are clarified in



After all

ls -l /usr/share/zoneinfo/US/Eastern
lrwxrwxrwx 1 root root 19 May 29  2023 /usr/share/zoneinfo/US/Eastern -> 
../America/New_York


For most of users I still recommend to stick to names like America/New_York.

I would not neglect IANA TZ DB just because it has usual disclaimer. 
Despite POSIX is a standard, I see efforts to keep TZ DB accurate. That 
is why reputation of IANA, Arthur David Olson, and Paul Eggert has more 
value for me.

Re: Local time in databases (Re: ntpsec as server questions)

[Max Nikulin]

On 07/12/2023 23:08, tomas wrote:

On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:

On 07/12/2023 21:22, John Hasler wrote:

Databases should never store local time.


There are exceptions when storing UTC instead of local time leads to
undesired consequences.


Heh. There was one huge thread in Emacs user about a year ago (don't
ask me in which time zone).


Perhaps you mean emacs-ormode. Then an important difference arises. 
Timestamp are stored not in a database, but in a plain text file and 
must be human readable, moreover some users prefer to type timestamps 
directly without dedicated commands.


Leaving aside future timestamps that may need local time, significant 
fraction of timestamps may be reliably represented in UTC. I still have 
no clue why some people were strongly against local time with explicit 
time offset "2023-12-07 17:08:50 +0100". From my point of view such 
format may be unambiguously mapped to UTC "2023-12-07T16:08:50Z" and 
more convenient for users residing in Europe/Berlin. There were 
participants insisting on either forcing UTC or using IANA identifiers 
"2023-12-07 17:08:50 Europe/Berlin". The latter format has issues close 
to backward DST time shifts and should be augmented with disambiguation 
hints.



After having a long and fruitless discussion with a customer (they
insisted in having local time in a log file, which is almost always
the wrong thing) I came to the conclusion that in such situations
it's best to give them what they want -- but store time zone *and*
time offset with it.


Local time is widely used in logs. The question is if the client can 
accept ambiguity


LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 00:30' '+%F %T'
2023-10-29 02:30:00
LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 01:30' '+%F %T'
2023-10-29 02:30:00

That are

LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 00:30' '+%F %T 
%z %Z'

2023-10-29 02:30:00 +0200 CEST
LANG=C.UTF-8 TZ=Europe/Berlin date -d 'TZ="Z" 2023-10-29 01:30' '+%F %T 
%z %Z'

2023-10-29 02:30:00 +0100 CET

Another case to consider it integration with 3rd party log analyzing 
tools and time formats that they can parse.


As I said above I see nothing wrong in local time with explicit time 
offset. Mail has been using it for decades:



Date: Thu, 7 Dec 2023 17:08:50 +0100

Re: debian forgot usr pw

[gene heskett]

On 12/7/23 20:24, Greg Wooledge wrote:

On Thu, Dec 07, 2023 at 08:06:52PM -0500, gene heskett wrote:

Thats bug #1. Single for rescue demands a root pw.


This isn't a bug.  It's just how things *are*.

People who choose not to set a root password are simply setting themselves
up for this failure.  It *will* happen eventually.  I strongly recommend
setting a root password on your systems.  And you should either *use* it
once in a while, so you don't forget what it is, or else make it the same
as your regular account's password.  So you don't forget what it is.

If you *still* choose not to set a root password, then you will need to
know how to get around the issue you ran into.  You won't be able to use
single-user mode to rescue your system, so you'll need other ways.  There
are two straightforward alternatives: boot from external media (USB or CD
or DVD), or learn how to do the "init=/bin/bash" thing from your boot
loader, which includes bind-mounting /proc and /dev and so on.

.
I've now set a root pw, about 34 chars, so they'll be a couple eons 
guessing it AND (horrors) have written it down.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: debian forgot usr pw

[Greg Wooledge]

On Thu, Dec 07, 2023 at 08:06:52PM -0500, gene heskett wrote:
> Thats bug #1. Single for rescue demands a root pw.

This isn't a bug.  It's just how things *are*.

People who choose not to set a root password are simply setting themselves
up for this failure.  It *will* happen eventually.  I strongly recommend
setting a root password on your systems.  And you should either *use* it
once in a while, so you don't forget what it is, or else make it the same
as your regular account's password.  So you don't forget what it is.

If you *still* choose not to set a root password, then you will need to
know how to get around the issue you ran into.  You won't be able to use
single-user mode to rescue your system, so you'll need other ways.  There
are two straightforward alternatives: boot from external media (USB or CD
or DVD), or learn how to do the "init=/bin/bash" thing from your boot
loader, which includes bind-mounting /proc and /dev and so on.

debian forgot usr pw

[gene heskett]

I had a 3d slicer I was quitting to restart it and re-organish its 
caxhe, took my machine to a lockup showing half a workspace on one half 
the screen and half an adjacent workspace on the other half of the 
screen, no responce to the keyboard and no mouse. 28 days uptime which 
was better than most uptimes I have with bookworm. 2 weeks seems to be 
the norm.


TL;DR:

So I went to the front panel and pressed the reset button but when it 
came time to enter my pw, it just looped back to the login prompt.  So I 
did a full powerdown, enough times the psu finally went face down in the 
pool.  That was a good excuse to do an overdue D & C and some update 
installs while I was changing the supply, adding a 16 port sata-III 
controller and 8T worth of SSD's so I could use them to get amanda 
started again. Powered it up, bios found the new drives, but my pw was 
still rejected, it looped back to the login in 2 or 3 seconds.


I do not normally have a root pw set, just me, using sudo when I need to 
do root stuff. So at grub I hit e and changed quiet to single, 
eventually spotting in all the spew, something go flying by about the 
root account being locked, so "single" does not work.  And of course no 
scrollback to read that msgs detail.


Thats bug #1. Single for rescue demands a root pw. If no root, it should 
default to the name in the sudoers file. So I'm still locked out and 
this is the 3rd time debian 12 has done this to me. So I get out a 12.2 
net-install dvd and reboot to it, several times, but I was able to set a 
root pw so single worked but I still had to enter the new pw.


At this point I successfully changed /my/ passwd to something a bit 
longer expressing my frustration. So since all my other machine control 
machines have a full desktop with full net access, I went to one of the 
bananapi-m5's and sent firefox to google with the search string "linux 
login loops back to login", 2nd hit, on stackexchange said to delete 
anything that looked like ./XAuthority* and ditto ./xsession* something 
was contaminated, killing x or its newer wayland cousin.  Bingo! Next 
reboot was normal.


So that is bug #3. Deleting that stuff, possibly losing some setup 
details by then re-starting X (etc) with a clean slate is far more 
preferable to another format and reinstall just to delete the 
contaminated files, formatting everything and losing 25 years of my 
history like happened when those 2 new 2T seacrates died at about 6 
weeks runtime, within hours of each other a bit over a year ago.


Seems to me stuff like this ought to be fixable.

Many thanks for reading this far. Maybe someone with write perms on 
bugzilla can investigate?


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: ToG Linux (first draft of a RFC) ...

[Albretch Mueller]

 Hopefully finally! We should brainstorm our initial thoughts about it
there and once we could envision some completion and continuing hope
to it, we can move it into a formal github open source project:

 https://ergosumus.wordpress.com/2023/12/07/tog-linux-first-draft-of-a-rfc/

 lbrtchx

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[John Hasler]

Turritopsis Dohrnii Teo En Ming wrote:
> UDM Pro runs Debian 11 (bullseye)

I have a Ubiquiti router.  Before I installed OpenWRT I explored the OS.
It uses packages from Bullseye but it is certainly not Debian.  You
couldn't find that file because it isn't there.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[jeremy ardley]

On 7/12/23 23:52, Turritopsis Dohrnii Teo En Ming wrote:

Subject: Could not find interfaces configuration file /etc/network/interfaces 
in Debian Linux 11 (bullseye)



You should confirm that the device is actually using that file.

There are at least three different network configuration services in 
Debian - which are not completely mutually exclusive


what is the result of these commands?

sudo systemctl status networking

sudo systemctl status systemd-networkd

sudo systemctl status NetworkManager

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Andy Smith]

Hello,

On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming wrote:
> UDM Pro runs Debian 11 (bullseye)

I don't think it does. Just because you found a file on the
filesystem that says it does, is as trustworthy as the claims in
your email that your client is called Henry Kissinger and your
colleague Edward Snowden.

It might have started out as Debian 11, but Ubiquiti have made
unknown changes to it.

> Linux United-States-Space-Command-Secret-Server 4.19.152-ui-alpine #4.19.152 
> SMP Thu Apr 6 21:41:48 CST 2023 aarch64 GNU/Linux

This is also not a kernel supplied by Debian.

> But another problem cropped up. Now we could not access the web UI
> of the UDM Pro.

[…]

> We could not putty (ssh) into the UDM Pro too.
> 
> May I know what the problem could be?

Given that you're running an operating system supplied by Ubiquiti
on hardware supplied by Ubiquiti using a web frontend written by
Ubiquiti on top of a kernel supplied by Ubiquii, I think you need to
ask Ubiquiti.

> Please advise.

I think it's for your vendor to advise.

Thanks,
Andy

PS It would also be advisable to get into the habit of using the
   "ip" suite of tools instead of deprecated ones like "ifconfig"
   and "route". The reason being that tools like ifconfig have not
   kept up changes in the Linux kernel and do not actually display
   all settings of the system any more. Most of the time the old
   ways will still work, but at some point you will encounter a
   situation where ifconfig etc is not showing you all of the
   settings. The diagnostic output can also be confusing to people
   born after the deprecation of ifconfig, for example.

   Your bigger problem though is that Debian didn't supply this
   hardware or software.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Dan Purgert]

On Dec 07, 2023, to...@tuxteam.de wrote:
> On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming 
> wrote:
> 
> [...]
> 
> > Problem
> > =
> > 
> > On 6 Dec 2023, our client discovered that their UDM Pro could not perform 
> > firmware updates automatically. Their UDM Pro was running UniFi OS version 
> > 3.0.20. Client wants to upgrade firmware to latest version 3.1.16 but 
> > couldn't.
> > 
> > UDM Pro runs Debian 11 (bullseye)
> > 
> 
> Now I don't understand: is it running UniFi OS or Debian bullseye?

"UniFi OS" (And EdgeOS on other lineups) is customized Debian Stable of
some flavor or other.

> 
> Or is Ubiquiti just cheapskating and sending their customers here
> to save on customer support?

I've never seen them direct customers anywhere other than their support
forums... 

-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[tomas]

On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming wrote:

[...]

> Problem
> =
> 
> On 6 Dec 2023, our client discovered that their UDM Pro could not perform 
> firmware updates automatically. Their UDM Pro was running UniFi OS version 
> 3.0.20. Client wants to upgrade firmware to latest version 3.1.16 but 
> couldn't.
> 
> UDM Pro runs Debian 11 (bullseye)
> 

Now I don't understand: is it running UniFi OS or Debian bullseye?

Or is Ubiquiti just cheapskating and sending their customers here
to save on customer support?

Inquiring minds...

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Local time in databases (Re: ntpsec as server questions)

[tomas]

On Thu, Dec 07, 2023 at 10:29:29PM +0700, Max Nikulin wrote:
> On 07/12/2023 21:22, John Hasler wrote:
> > Databases should never store local time.
> 
> I am anticipating a new branch of hot discussion.
> 
> There are exceptions when storing UTC instead of local time leads to
> undesired consequences.

Heh. There was one huge thread in Emacs user about a year ago (don't
ask me in which time zone).

You are right. Sometimes local time is the right thing. Sometimes it's
the wrong thing. Context matters and so on.

After having a long and fruitless discussion with a customer (they
insisted in having local time in a log file, which is almost always
the wrong thing) I came to the conclusion that in such situations
it's best to give them what they want -- but store time zone *and*
time offset with it.

> Planned (future) events may be bound namely to local time. So if timezone
> offset rules are changed [...]

Yep, that's one of those. Even on a planned change -- regular planned
events are local time: show up at work at 10 o'clock means local time.

[...]

The intersection of technology and "human stuff" is often messy. Look
closely at Unicode to have yet another bunch of fun :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: ToG Linux (first draft of a RFC) ...

[Albretch Mueller]

 BTW, except for the GRUB/boot loading phase and its possible useful
aspects relating to ToG-L (which I haven't found the time to study), I
would say that 80%+ of the whole project I have already implemented
with my lousy bash scripts skills and in java/GRAALVM as a first
"proof of concept" and of the rest of it I have kept a thoroughgoing
functional mental map. I have had to fight such issues for a long time
and I initially thought of such things as ad hoc momentary solutions
to be able to use the Internet, but at some point I started to think
of it in an articulate and comprehensive way.

> 2.5)* where are the knoppix-like boot options: "toram",
> "tohd=", "fromhd=", "myconf=<...>", "home=<...>"
> in Debian Live?

 We all know that a DVD caddy could be easily bugged as well (the USPS
keeps stocks of all kinds of equally looking things which are bugged)
and  a DVD caddy is more of a mechanical, more power consuming thing,
so it would be ideal to go the knoppix-like "toram" way. Knoppix these
days is based a debian, so figuring out the grub hack to pass start up
arguments to the kernel at boot time shouldn't be difficult. You would
also be freeing the DVD port in case you need it.

> 6.1)* you will have to keep one in your backpack inside of a
> protective box or use a partition of your USB pendrive to boot your
> computer (ideally if some sort of knoppix-like fromhd boot option is
> used, there should be an option to check the size, type and sha*sum of
> the iso)

 "bootfrom" would be also nice (I think in knoppix you can even
combine the "bootfrom=<...>.iso" and "toram" start up options!). These
days it doesn't matter much because you could use WSL (Windows
Subsystem for Linux), but for whatever reason you may want to just use
Linux.

> ... that thing they used to call "privacy".

 I am old enough to remember the times in which telling someone that:
"you care about their privacy" would have been taken as an odd joke.
It would tacitly mean that -you have no privacy whatsoever-! Privacy
is one of those things you would have to take care of yourself! (ToG-L
would enable "we the people" to do so) In some European countries not
just the government has implanted chips in military personnel, but
your boss would make it a precondition to be hired even though it
doesn't relate to your job description in the least! "We the people"
would get chipped just to be part of a dance club! Some government
have had ideas about chipping everyone which makes you wonder if
people have started to lose their senses "in the end of times" ...

 Einstein who made his main occupation the mathematically measurable
aspect of the it, mind you, said: "two things are infinite: the
universe and human stupidity; and I'm not sure about the universe".

 I am not trying to be persuasive anyone. I actually think in the
times we are living things have gotten more than half way off for way
too long and we, scientists, tech monkeys and Mathematicians could and
should inform "we the people" and help them more actively have their
stand on, way out of such issues.

 lbrtchx

Re: ntpsec as server questions

[David Wright]

On Thu 07 Dec 2023 at 09:37:29 (-0500), Pocket wrote:
> On 12/7/23 09:22, John Hasler wrote:
> > Greg writes:
> > > You'd think that you can determine the length of the test by
> > > subtracting the start time from the end time, right?
> > That would have worked had the times been stored as UTC (better yet, TAI
> > or Unix time since UTC can cause a similar problem).  Databases should
> > never store local time.
> 
> Yes that is true.
> 
> I use UTC on all my systems as I have some windows machines, one win
> xp dell laptop and two win 7 one laptop and one desktop.

That must be very confusing if you mean that, for example,
the bash prompt after you'd just sent that post said:

  hostname!pocket 14:38:29 ~$ 

Even if databases store UTC, they have to have front ends on local
time for data entry and reporting, unless you're going to have no
human involvement. And those original dates and times need to be
preserved or recreatable for auditing against any contemporary
records that are in local time. There may be several "local times"
in use in large organisations.

Cheers,
David.

Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

Subject: Could not find interfaces configuration file /etc/network/interfaces 
in Debian Linux 11 (bullseye)

Good day from Singapore,

Background Information
===

Initially our client has a UniFi Dream Machine Pro (UDM Pro) acting as a 
firewall and router. Port 9 (WAN1) on the UDM Pro was connected to the ONT. 
Port 1 on the UDM Pro was connected to the LAN switch.

Then our client purchased Fortigate 80F firewall from us.

The date of the deployment of the Fortigate 80F firewall is 26 May 2023.

During the setup and installation, I had connected WAN1 on the Fortigate 80F 
firewall to the ONT. Then I need to convert UDM Pro to non-routing mode. RJ45 
cable to Port 9 (WAN1) on the UDM Pro was removed. I proceeded to connect Port 
1 on the UDM Pro to Port 1 on the Fortigate 80F firewall. As the Fortigate 80F 
firewall already had DHCP server configured, I disabled the DHCP server inside 
UDM Pro.

Everything (the network infrastructure) was working well for 6 months 11 days 
until 6 Dec 2023.

Problem
=

On 6 Dec 2023, our client discovered that their UDM Pro could not perform 
firmware updates automatically. Their UDM Pro was running UniFi OS version 
3.0.20. Client wants to upgrade firmware to latest version 3.1.16 but couldn't.

UDM Pro runs Debian 11 (bullseye)


When I putty (SSH) into the UDM Pro machine, I executed the command "cat 
/etc/os-release".

The output is:

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";

The output of the "uname -a" command is:

Linux United-States-Space-Command-Secret-Server 4.19.152-ui-alpine #4.19.152 
SMP Thu Apr 6 21:41:48 CST 2023 aarch64 GNU/Linux

Troubleshooting


Troubleshooting date is 6 Dec 2023 Wednesday.

When I run "netstat -nr" or "route" commands in UDM Pro, the output shows that 
the default gateway for the 0.0.0.0/0.0.0.0 destination is 192.168.2.2. 
192.168.2.2 is the IP address of the Fortigate 80F firewall. This confirms that 
the gateway was correctly configured on the UDM Pro. The LAN IP address of the 
UDM Pro is 192.168.2.1.

The UDM Pro could reach the gateway 192.168.2.2, in this case the Fortigate 80F 
firewall.

I could ping the gateway 192.168.2.2 from within the UDM Pro CLI.

However, I could not ping 1.2.3.4 or 8.8.8.8.

Even with the gateway correctly configured on the UDM Pro, it could not reach 
the outside world.

When I run the command "ifconfig br0", the broadcast shows up as 0.0.0.0. I 
thought this is wrong. So I ran the following Linux command to correct it.

# ifconfig br0 broadcast 192.168.2.255

But it did not solve the problem.

My colleague Henry Kissinger told me that Port 9 (WAN1) on the UDM Pro must be 
connected (seems like a design flaw). I had wanted to configure the network 
interfaces using the /etc/network/interfaces file. But I could not find it 
anywhere in the terminal in Debian 11. Where can I find this file in Debian 11? 
It is missing!

I had no choice but to use the web UI of the UDM Pro to configure Port 9 
(WAN1). I had asked the client to connect Port 9 (WAN1) on the UDM Pro to Port 
5 (LAN) on the Fortigate firewall. Then I configure Port 9 (WAN1) on the UDM 
Pro with the following network parameters:

Static IPv4 address: 192.168.2.254
Subnet mask: 255.255.255.0
Default Gateway: 192.168.2.2

After configuring Port 9 (WAN1) on the UDM Pro, I could ping 8.8.8.8 from 
inside the UDM Pro already. However, I still could not ping www.google.com. 
That means DNS name resolution has failed. I had to edit /etc/resolv.conf.

# vi /etc/resolv.conf
nameserver 8.8.8.8

Now I could ping www.google.com from inside the UDM Pro. Name resolution is 
working after I have modified the /etc/resolv.conf file by hand.

My client Edward Joseph Snowden then initiated the firmware upgrade using the 
web UI. After the firmware upgrade, the UDM Pro rebooted. Yes, it did reboot. I 
can confirm. The LCD screen on the UDM Pro shows that the firmware has been 
successfully upgraded to version 3.1.16. We have the screenshots to show it.

Everything is working. All the UniFi wireless access points are working. All 
the laptops and mobile phones have internet access. But another problem cropped 
up. Now we could not access the web UI of the UDM Pro.

https://192.168.2.1 of the UDM Pro (LAN IP address) is now not accessible.
https://192.168.2.254 of the UDM Pro (Port 9 (WAN1)) is also not accessible.

We could not putty (ssh) into the UDM Pro too.

May I know what the problem could be? I think there's no choice now but to 
factory reset the UDM Pro and restore configuration from the most recent 
backup. Our client says their most recent backup was on 16 Sep 2023.

Please advise.

Thank you very much.

Regards,

Mr. Turritopsis Dohrnii Teo En Mi

Local time in databases (Re: ntpsec as server questions)

[Max Nikulin]

On 07/12/2023 21:22, John Hasler wrote:

Databases should never store local time.


I am anticipating a new branch of hot discussion.

There are exceptions when storing UTC instead of local time leads to 
undesired consequences.


Planned (future) events may be bound namely to local time. So if 
timezone offset rules are changed due to new administrative regulations 
then UTC timestamp becomes invalid. I do not mean regular spring and 
fall time transitions related to DST. It may be decided to cancel or to 
introduce DST, to shift dates when it is effective, to change time 
offset for some territory. 10:00am local time remains 10:00am despite 
before a new bill it is 15:00 UTC and it will be 14:00 UTC after. This 
is a case for various calendar applications.


Historical documents specify local time. Time zone database may contain 
incorrect data. Fixing TZ DB should not change local time for the stored 
event.


Additional data may be required when local time is stored: time zone 
identifier, disambiguation rule in the case of backward time transition 
close to the event time, location for the case that existing time zone 
will be split.


Despite calculation may be performed using UTC timestamps, local time is 
definitive in these cases.

Re: ntpsec as server questions

[Pocket]

On 12/7/23 09:22, John Hasler wrote:

Greg writes:

You'd think that you can determine the length of the test by
subtracting the start time from the end time, right?

That would have worked had the times been stored as UTC (better yet, TAI
or Unix time since UTC can cause a similar problem).  Databases should
never store local time.


Yes that is true.

I use UTC on all my systems as I have some windows machines, one win xp 
dell laptop and two win 7 one laptop and one desktop.


The dell seems to be too old to use bookworm and the others are used for 
apps that only run on windows (3d cad engineering)


I just purchased a new laptop yesterday (the price was too good to pass 
up)  so I guess I will find out the trials and tribulations of 
installing bookworm on a new machine with secure boot and the new boot 
systems.  I have only have experience with BIOS boot loaders.


Maybe there will be another thread for that ;)

--
It's not easy to be me

Re: ntpsec as server questions

[John Hasler]

Greg writes:
> You'd think that you can determine the length of the test by
> subtracting the start time from the end time, right?

That would have worked had the times been stored as UTC (better yet, TAI
or Unix time since UTC can cause a similar problem).  Databases should
never store local time.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: ntpsec as server questions

[Pocket]

On 12/7/23 07:16, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 11:46:50PM -0600, David Wright wrote:

On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote:

Which BTW this whole discussion about timezones is just water over the dam.

The system should be set to UTC, the "timezone" issue is really just a
"human" issue as the UTC clock is always correct

While I'm glad we're not discussing whether or not the RTC is set to
UTC or TAI or local time, I do want my computers to display to /me/ the
correct date and time corresponding to my location. And when I travel,
I expect my phone to switch its display automatically, using some
reasonably up-to-date tables.

I haven't had time to read and follow up on Pocket's list of references,
but I'd like to respond to these points with a real anecdote.

One of our systems at work uses a database with a web front end, where
users input the starting and ending times of medical tests that have
been performed on a patient.  When the tests are finished, and all the
data have been entered, billing charges are generated, and these charges
depend on the length of the test.

You'd think that you can determine the length of the test by subtracting
the start time from the end time, right?  Unfortunately, that fails
two times a year, if you don't do it exactly right.  The naive approach
of simply looking at the time field ("test started at 01:45 and ended
at 03:15 the same day, so it must have lasted 90 minutes") is wrong.
You have to look at the entire date-plus-time as a single timestamp,
and interpret it within the correct time zone.  That test might have been
90 minutes, or it might have been 30 minutes, or it might have been 150
minutes, depending on whether a DST transition happened in that interval,
and which way the clock moved.

I *literally* had to fix that bug (in March).  This isn't hypothetical.



I worked with time keeping systems for a major player in the business 
back in 1995.


That feature of the government reared its ugly head back then as well.

People get more irate when they are not payed properly then they are 
from being over billed,


trust me been there done that.




Of course, the system I'm dealing with only covers tests that have been
performed recently, not tests from a century ago.  So the historical
interpretation of times under previous government DST rules *is*
hypothetical as far as this anecdote goes.  But I hope some of you can
appreciate it nonetheless.


--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 11:46:50PM -0600, David Wright wrote:
> On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote:
> > Which BTW this whole discussion about timezones is just water over the dam.
> > 
> > The system should be set to UTC, the "timezone" issue is really just a
> > "human" issue as the UTC clock is always correct
> 
> While I'm glad we're not discussing whether or not the RTC is set to
> UTC or TAI or local time, I do want my computers to display to /me/ the
> correct date and time corresponding to my location. And when I travel,
> I expect my phone to switch its display automatically, using some
> reasonably up-to-date tables.

I haven't had time to read and follow up on Pocket's list of references,
but I'd like to respond to these points with a real anecdote.

One of our systems at work uses a database with a web front end, where
users input the starting and ending times of medical tests that have
been performed on a patient.  When the tests are finished, and all the
data have been entered, billing charges are generated, and these charges
depend on the length of the test.

You'd think that you can determine the length of the test by subtracting
the start time from the end time, right?  Unfortunately, that fails
two times a year, if you don't do it exactly right.  The naive approach
of simply looking at the time field ("test started at 01:45 and ended
at 03:15 the same day, so it must have lasted 90 minutes") is wrong.
You have to look at the entire date-plus-time as a single timestamp,
and interpret it within the correct time zone.  That test might have been
90 minutes, or it might have been 30 minutes, or it might have been 150
minutes, depending on whether a DST transition happened in that interval,
and which way the clock moved.

I *literally* had to fix that bug (in March).  This isn't hypothetical.

Of course, the system I'm dealing with only covers tests that have been
performed recently, not tests from a century ago.  So the historical
interpretation of times under previous government DST rules *is*
hypothetical as far as this anecdote goes.  But I hope some of you can
appreciate it nonetheless.

Re: Problem between kernel 6.5.0-5 (testing) and Realtek NICs ?

[Erwan David]

Le 06/12/2023 à 16:44, Erwan David a écrit :

Le 06/12/2023 à 15:55, Erwan David a écrit :
After upgrade to 6.5.0-5 (a 6.5.13 kernel in testing), impossible to 
use the laptop when Realtek card present (in dock). it boots, sddm 
works but anything which tries to access networking (even the ip 
command) is then blocked


It could be the same problem as in 
https://discussion.fedoraproject.org/t/kernel-6-5-12-or-later-on-fedora-39-broken-network-on-lenovo-t570/97586/18


I'll try installing the realtek-formware package, but the fedora 
discussion does not give much hope...



Ok, it works with firmware-realtek package, from the non-free-firmware 
section (which should be added in /etc/apt/sources.list if not already 
present)


SO, it worked yesterday (but I booted in recovery mode) not today. I'll 
have to do a reportbug for a non running kernel...

Re: ToG Linux (first draft of a RFC) ...

[Arno Lehmann]

Hello,

it's quite interesting that you use a platform such as wordpress, 
running code you can not control, to discuss such matters.


Wouldn't it be more reasonable to self host, using a hoster providing 
decent privacy and aonymity or a technology such as Tor? Given the 
amount of time and effort you put into your draft, that would not be a 
big overhead, I think. It would, however, make it clearer that you 
actually mean it.


Also, what I know about secure, air-gapped systems, can be summarized 
quite easily:


- You can not use the same hardware air gapped and non air gapped.
- Maintaining such systems is a pain.
- There are no shortcuts.

Small anecdote: A colleague recently visited a US agencies secure site 
to help them with some software deployment. He could bring one DVD-R, 
not -RW, there. No electronic equipment.


There are no USB keys, portable disks, or dual-booting devices 
repeatedly crossing the boundaries there. In particular, there are no 
exceptions. What you bring in is thoroughly examined and stays in.



All your fancy ideas seem to be about bridging the gap. This will not 
create security.


Cheers,

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Re: Upgrade to 12.3 fails due to missing nvidia firmware package

[Harald Dunkel]

On 2023-12-06 17:20:16, Sven Joachim wrote:


Maintainer uploads to (old)stable are staged in proposed-updates, so you
would have to enable bookworm-proposed-updates to install the new
version of firmware-nvidia-gsp.



I missed the non-free-firmware for bookworm-updates and
bookworm-proposed-updates. My bad, sorry. Thank you for your
help


Regards

Harri