Re: syncthing, rsync for git; was: git setup

[Max Nikulin]

On 23/08/2023 02:27, Michael Kjörling wrote:

I know of rsync's shortcomings in the bidirectional-sync use case
because I looked for a good while for a way to get it to do that
safely, before coming across unison which being designed for that
solved that problem with for all intents and purposes no fuss at all.


Almost every version control system (besides legacy ones, e.g. RCS) is 
designed to combine changes from multiple working copies evolving in 
parallel.


Of course, git facilities allows to synchronize multiple repositories 
with minimal risk to loose changes committed to any copy. The idea has 
been posted in this thread already, see

Sven Joachim. Tue, 22 Aug 2023 17:28:40 +0200.
https://lists.debian.org/msgid-search/87h6orf653@turtle.gmx.de
setup an "upstream" *bare* repository that may reside on the same 
machine or accessed through ssh and add it using "git remote" to 
existing working copies (new ones created by "git clone" will have it).


You may need to set tracking for existing branches. Generally you may 
follow guides for git hosting services, some open source projects have 
their own introductions for git novices. You may e.g. choose a branch 
per working copy to be able to combine commits from any of them. Balance 
of "git merge" and "git rebase" is mater of taste in respect to linear 
commit history.


A policy for a *backup* repository may be different from an "upstream" 
one. Backup repositories should allow to recover after accidental force 
push to some old commit. Warning: "git push --mirror" does force push at 
least by default, use it with care. You may either fetch or push to 
backup repository depending on current working directory. When used 
properly, it is safer than general purpose synchronizing tools.


A single branch may be pushed to an "upstream" or a "backup" repository 
without permanently adding it as a remote by specifying path to that 
repository


git push user@host:/path/to/repository.git master

I would limit usage of rsync and similar tools to rather specific cases 
when git repositories are involved:

- copy data when you are going to decommission a disk
- working copy contains untracked files having some value or temporary 
branches undesired in upstream and backup repositories.

BASH {VARNAME}>&- redirection (was: Re: Konsole is not bash)

[Max Nikulin]

On 23/08/2023 02:59, Greg Wooledge wrote:

bar() {
 local fd
 foo {fd}>&1 1>&2 2>&${fd} {fd}>&-
}

Running this appears to gives the correct results -- outputs go to the
right places -- but it leaves the temporary FD open.  The final
redirection to close it doesn't work.


At first glance it is documented and effect of {fd}>&- is limited to the 
function call


info "(bash) Redirections"

If {VARNAME} is supplied, the redirection persists
beyond the scope of the command, allowing the shell programmer to manage
the file descriptor's lifetime manually.  The 'varredir_close' shell
option manages this behavior (*note The Shopt Builtin::).


info "(bash) The Shopt Builtin"

 'varredir_close'
  If set, the shell automatically closes file descriptors
  assigned using the '{varname}' redirection syntax (*note
  Redirections::) instead of leaving them open when the command
  completes.


However the redirection does not persist if an external executable is 
called instead of a BASH function. Perhaps it should be discussed with 
BASH developers.


foo() {
sh -c 'echo "internal $1" /proc/self/fd/*' foo "$1"
}
bar() {
local fd
sh -c "echo 'external before' /proc/self/fd/*"
sh -c "echo 'external closed' /proc/self/fd/*" {fd}>&1 1>&2 
2>&${fd} {fd}>&-

sh -c "echo 'external after ' /proc/self/fd/*"
echo "fd: $fd"
sh -c "echo 'external before' /proc/self/fd/*"
sh -c "echo 'external open  ' /proc/self/fd/*" {fd}>&1 1>&2 2>&${fd}
sh -c "echo 'external after ' /proc/self/fd/*"
echo "fd: $fd"
echo
sh -c "echo 'internal before' /proc/self/fd/*"
foo "closed" {fd}>&1 1>&2 2>&${fd} {fd}>&-
sh -c "echo 'internal after ' /proc/self/fd/*"
echo "fd: $fd"
if [ -n "$fd" ]; then exec {fd}>&-; fd=; fi
sh -c "echo 'internal before' /proc/self/fd/*"
foo "open  " {fd}>&1 1>&2 2>&${fd}
sh -c "echo 'internal after ' /proc/self/fd/*"
echo "fd: $fd"
if [ -n "$fd" ]; then exec {fd}>&-; fd=; fi
}
bar

Pay attention to {fd} that is is 10, other may be ignored, in particular 
/proc/self/fd opened by readdir is 3, some inotify is 20 below.


external before /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 
/proc/self/fd/20 /proc/self/fd/3
external closed /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 
/proc/self/fd/20 /proc/self/fd/3
external after  /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 
/proc/self/fd/20 /proc/self/fd/3

fd:
external before /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 
/proc/self/fd/20 /proc/self/fd/3
external open   /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/10 
/proc/self/fd/2 /proc/self/fd/20 /proc/self/fd/3
external after  /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 
/proc/self/fd/20 /proc/self/fd/3

fd:

internal before /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 
/proc/self/fd/20 /proc/self/fd/3
internal closed /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 
/proc/self/fd/20 /proc/self/fd/3
internal after  /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/10 
/proc/self/fd/2 /proc/self/fd/20 /proc/self/fd/3

fd: 10
internal before /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 
/proc/self/fd/20 /proc/self/fd/3
internal open   /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/10 
/proc/self/fd/2 /proc/self/fd/20 /proc/self/fd/3
internal after  /proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/10 
/proc/self/fd/2 /proc/self/fd/20 /proc/self/fd/3

fd: 10

GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)

Greg Wooledge

bar() {
 local fd rc
 foo {fd}>&1 1>&2 2>&${fd}
 rc=$?
 exec {fd}>&-
 return "$rc"
}


I have not tested if "trap" is more robust in the presence of "set -e -o 
pipefail". I know, there are enough pitfalls with this options.



At this point, the "pure sh" version looks a whole lot simpler,
doesn't it?


You mentioned the limitation: a spare file descriptor must be known.

Re: Debian Wiki IP Address Unban Request

[Greg Wooledge]

On Tue, Aug 22, 2023 at 05:02:22PM -0400, Oliver Wenston wrote:
> I purchased a vps to use as my vpn server, and found out that it was black
> listed from the https://wiki.debian.org/ website. I am currently using
> Bookworm, and would love to be able to visit the wiki with my vpn.
> 
> Who should I contact next on a private channel to get my IP unbanned? Thank
> you very much.

>From :

Access to wiki.debian.org is blocked with 403 Forbidden

Please mail w...@debian.org with your IP address 

Re: No korganizer, kmix, akregator icon in the task bar (but yes for kwrite...)

[Carles Pina i Estany]

Hi,

Answering myself...

On 22 Aug 2023 at 16:50:15, Carles Pina i Estany wrote:


> Bookworm here, but the same issues (at least for korganizer) happened on
> bullseye.

[...]

> I use LXDE with some KDE applications. Some applications such as
> korganizer, kmix, akregator: in the task bar I have a generic LXDE icon
> (or the top-left icon if I have the application visible)
> 
> Other applications such as kcalc, kwrite or kate have the icons as
> expected.

The apps where the icon is displayed have calls such as:

app.setWindowIcon(QIcon::fromTheme(QStringLiteral("accessories-calculator"), 
app.windowIcon()));

or:

QApplication::setWindowIcon(QIcon(QStringLiteral(":/kwrite/kwrite.svg")));

The ones without the application icons... do not have this calls to set
it up.

I'll investigate a bit more and report to upstream.

Cheers,

-- 
Carles Pina i Estany
https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat

Debian Wiki IP Address Unban Request

[Oliver Wenston]

Dear Debian mailing list,

I purchased a vps to use as my vpn server, and found out that it was black
listed from the https://wiki.debian.org/ website. I am currently using
Bookworm, and would love to be able to visit the wiki with my vpn.

Who should I contact next on a private channel to get my IP unbanned? Thank
you very much.

Best regards,
Oliver

Re: UEFI op servers, of niet?

[Paul van der Vlis]

Hoi Dennis, en anderen natuurlijk,

Op 22-08-2023 om 12:22 schreef Dennis van Dok:

On 22-08-2023 11:54, Paul van der Vlis wrote:

Hallo Dennis en anderen,

Op 22-08-2023 om 10:45 schreef Dennis van Dok:

On 15-08-2023 12:13, Paul van der Vlis wrote:


We zijn (bij Nikhef, plusminus 500 systemen) al een paar jaar 
helemaal over op EFI boot aangezien de nieuwere systemen legacy 
helemaal niet meer ondersteunen. 


Daar heb ik nog geen last van bij servers, bij welke fabrikanten zie 
je dat?


IIRC Dell en Lenovo, in combinatie met ondersteuning voor PXE boot en 
grote NVMe drives.


Hebben ze dan helemaal geen "legacy" meer?  Of wordt dat steeds beperkter?

Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden. 


Ik ken dit eigenlijk alleen van kleinere systemen om eerlijk te zijn, 
bijvoorbeeld van Dell. Maar qua 19" systemen gebruik ik Supermicro en 
dat doet nog niet mee.  Dit is wat ik bedoel:

https://packages.debian.org/bullseye/fwupd
https://fwupd.org/


Ik ga daar nog wel eens naar kijken want het lijkt me toch wel handig om 
te automatiseren (als dat kan). En natuurlijk altijd met de Bewuste 
Keuze™ welke updates je doorvoert!


Het punt is dat het nogal automatisch gaat, ik heb het nog niet helemaal 
onder controle. Dit komt ook omdat de hardware die ikzelf gebruik het 
niet ondersteund.


Ik gebruik in de praktijk geen software van de fabrikant, het is 
allemaal Debian.


DELL heeft racadm en dat werkt nog vrij aardig standalone, maar we 
stappen meer en meer over op redfish.


Dat kende ik nog niet, ik vond hier wel wat informatie:
https://en.wikipedia.org/wiki/Redfish_(specification)

Maar helemaal duidelijk is het me nog niet wat het doet.

Ik gebruik IPMI en serial-over-lan:
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
Maar daar staat: "The successor to the IPMI is Redfish" Dus wellicht 
moet ik er wel naar gaan kijken.


Zijn er OSS tools voor om bijvoorbeeld het bootproces en de bios remote 
te bekijken?  Dat is eigenlijk het enige waar ik het voor gebruik.

Oh ja, ook om te checken of er een voeding is.

Ik heb altijd met software RAID gewerkt en zie niet veel voordelen aan 
hardware RAID. Er zijn wel voordelen, maar ook nadelen.


Voordelen van software RAID vind ik:
- Het is heel generiek, een disk past zo in een andere machine zonder 
dat die ook zo'n kaart nodig heeft.


Doe je dat dan vaak, schijven uitwisselen tussen apparaten?


Nee, maar het is toch wel belangrijk als nood-scenario, en om te 
migreren naar nieuwe hardware.


Er zou maar een moederbord kapot gaan, dat is me weleens gebeurd. Ik zet 
er dan een andere machine neer, en zet de disks over. Ik heb reserve 
machines (oudere machines die het nog doen).



- De RAID kaart kan kapot gaan, je moet eigenlijk een spare hebben.


Dit is nou een van de componenten die ik zelden tot nooit heb zien falen.


Toch is mij altijd geleerd dat je zo'n kaart op voorraad moet hebben, 
anders kun je je disks niet meer lezen, ook niet met een andere machine.


Wellicht hebben jullie vele machines met dezelfde RAID kaarten, dan 
speelt dat minder.



- Tools zijn vaak closed source, en complex.


We configgen die meuk direct vanuit het BIOS (of laten dat vooraf doen 
door de leverancier) of anders is het Megaraid storcli (ja, beetje 
ingewikkeld wel).


Je moet het toch monitoren, je wilt weten dat er een disk kapot is. En 
ik wil met opensource software werken. Dat geheel maakt het wel lastig.


- Volgens mij moet je bij hardware RAID rebooten als je een disk wilt 
vervangen. (En misschien zelfs wachten tijdens het rebuilden.)


Al onze storage systemen doen hot-swapping dus misschien moet je een 
ander merk uitkiezen?


Misschien is het inderdaad simpel. Ik heb ooit ergens een disk 
verwisseld waar het toch een gedoe was. Maar weinig ervaring met 
hardware raid eigenlijk.



- Je zit directer op de disk, er zit geen kaart tussen


En wat is daarvan nou het specifieke voordeel?


Ik stel het me zo voor dat als je bijvoorbeeld SMART tools gebruikt, je 
niet direct bij de disk kunt.



- Reuze veel mogelijkheden


Ben ook benieuwd!


https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm

Kun jij bijvoorbeeld disks vervangen door grotere, de partities en het 
filesystemen vergroten, terwijl alles gewoon doordraait? Ik wel.



Nadelen van software RAID vind ik:


- Niet geschikt voor systemen met heel veel disks (in elk geval was 
dat vroeger zo).


Ik weet dat we ook wel eens een wat grotere software raid setup hebben 
gedraaid (in de speeltuin) en dat werkte ook prima.


Het had te maken met het feit dat het meer dataverkeer gaf op de PCI 
bus, want elke disk moest apart worden aangestuurd. En bij hardware RAID 
moest alleen de RAID kaart worden aangestuurd. Maar dit kan ondertussen 
alweer anders zijn.


Voor zover ik weet is het een niet echt sneller dan het ander, maar 
misschien vergis ik me daarin.


Nee, dat zal ook niet het argument zijn. Er zijn trouwens behoorlijke 

Re: syncthing, rsync for git; was: git setup

[Celejar]

On Tue, 22 Aug 2023 19:27:57 +
Michael Kjörling <2695bd53d...@ewoof.net> wrote:

> On 22 Aug 2023 14:33 -0400, from cele...@gmail.com (Celejar):
> >> Git tends to be very rsync-friendly.
> > 
> > I do something similar - I use syncthing to automatically keep the git
> > repositories on two of my machines in sync. rsync may be better, but
> > syncthing has more or less worked for me.
> 
> I'm not really familiar with syncthing, but it looks like it and rsync
> solve somewhat different problems; rsync being primarily intended to
> update one location (the destination) to match another (the source),
> whereas syncthing is primarily intended to update both locations such
> that they match (but can be run in one-way mode if desired).
> 
> Therefore syncthing would seem to be more analogous to unison than to
> rsync.

Correct. My use case is two systems both used for development
(I work sometimes on a laptop and sometimes on a desktop). I understand
that this is not the OP's case and the subject of the thread, and I
apologize for the confusion.

> I know of rsync's shortcomings in the bidirectional-sync use case
> because I looked for a good while for a way to get it to do that
> safely, before coming across unison which being designed for that
> solved that problem with for all intents and purposes no fuss at all.

-- 
Celejar

Re: Konsole is not bash

[Greg Wooledge]

See, this is why I hate using bash extensions.  So many weird corner
cases and surprises

As it turns out, the answer I gave yesterday was only partially correct.
The "pure sh" solution is fine, but I offered this bash alternative:

cmd {fd}>&1 1>&2 2>&$fd {fd}>&-

This doesn't actually work as expected.  It fails to close the FD in the
final redirection.

What does it actually do?  Hell if I know.  I literally can't figure it
out.

Consider this function:

foo() { echo out; echo err >&2; }

Simple enough, right?  It writes "out" to stdout, and "err" to stderr.  We
can use this to see what's going where, while we play games with
redirections.

Next, we write a simple wrapper, which should in theory swap stdout and
stderr:

bar() { 
local fd
foo {fd}>&1 1>&2 2>&${fd} {fd}>&-
}

Running this appears to gives the correct results -- outputs go to the
right places -- but it leaves the temporary FD open.  The final
redirection to close it doesn't work.

But *this* one works:

bar() { 
local fd
foo {fd}>&1 1>&2 2>&${fd}
exec {fd}>&-
}

Why?  Again, I do not know.  My theories all fail to account for all of
the observed results.  And, of course, if we wanted to preserve the exit
status of foo, the second wrapper script doesn't do that.  It'll need
another variable to hold that:

bar() { 
local fd rc
foo {fd}>&1 1>&2 2>&${fd}
rc=$?
exec {fd}>&-
return "$rc"
}

At this point, the "pure sh" version looks a whole lot simpler,
doesn't it?

THIS is why I have a wiki devoted to bash and its problems.

Re: syncthing, rsync for git; was: git setup

[Michael Kjörling]

On 22 Aug 2023 14:33 -0400, from cele...@gmail.com (Celejar):
>> Git tends to be very rsync-friendly.
> 
> I do something similar - I use syncthing to automatically keep the git
> repositories on two of my machines in sync. rsync may be better, but
> syncthing has more or less worked for me.

I'm not really familiar with syncthing, but it looks like it and rsync
solve somewhat different problems; rsync being primarily intended to
update one location (the destination) to match another (the source),
whereas syncthing is primarily intended to update both locations such
that they match (but can be run in one-way mode if desired).

Therefore syncthing would seem to be more analogous to unison than to
rsync.

I know of rsync's shortcomings in the bidirectional-sync use case
because I looked for a good while for a way to get it to do that
safely, before coming across unison which being designed for that
solved that problem with for all intents and purposes no fuss at all.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: git setup

[Celejar]

On Tue, 22 Aug 2023 16:31:58 +0200
 wrote:

> On Tue, Aug 22, 2023 at 09:16:47AM -0500, John Hasler wrote:
> > Christoph writes:
> > > I have almost the same setup and use local git repositories.  Instead
> > > of syncing them by the git tools I use rsync to update the backup from
> > > time to time. This is a dumb method but it works.
> > 
> > This is what I do as well.
> 
> Actually... not that dumb. Git tends to be very rsync-friendly. In some
> weird way, this is no coincidence.

I do something similar - I use syncthing to automatically keep the git
repositories on two of my machines in sync. rsync may be better, but
syncthing has more or less worked for me.

-- 
Celejar

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Marco Möller]

On 19.08.23 21:19, Christoph K. wrote:

Could you please recommend a "suitable" sans-serif font that
a) (...)
b) (...)
c) (...)
d) (...)
Thanks,
Christoph


Having had the same problem to solve for myself I ended up to use:
Noto sans   for all my GUI
Liberation Mono for coding

Especially the "Liberation Mono" font is nicely readable for avoiding 
any letter misunderstanding when coding, and I tested much more 
problematic cases than only T71Iil15So0QOUuwWMNmn (this are just the 
ones I spontaneously remember). There are more Liberation fonts, but I 
didn't check them out. "Noto sans", which I selected already before for 
the GUI decorations, was already clear enough for that purpose.

Good luck!
Marco

Re: Debian installer preseed fails

[Ceppo]

On Sun, Aug 20, 2023 at 02:34:20PM +, Michael Kjörling wrote:
> I think you also want:
>
> d-i hw-detect/firmware-lookup string never

Maybe a dumb question, but doesn't it prevent free firmware from being
installed too?

--
Ceppo

Re: git setup

[Charles Curley]

On Tue, 22 Aug 2023 09:28:00 +0200
john doe  wrote:

> To me you only update upstream by pushes and never by pulling!
> 
> So my suggestion in your case would be:
> - One repo to work in and to push to upstream
> - One upstream bare repo

This is essentially what I do. My master repo, which the OP would call
BACKUP, is on a headerless machine, so I used gitolite there, and git
administration is all over ssh. That gets backed up daily using amanda.

I have two laptops, a desktop and a plethora of other machines. Each of
those has such repos as are appropriate to that machine. All of them
push to and pull from the gitolite machine.

The trick is a bit of discipline: When ending a session on any machine,
be sure to push it to the gitolite repo. And when starting a session,
be sure to pull from the gitolite repo. That keeps things in synch.

KISS: Keep It Simple, Stupid!

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: git setup

[Ceppo]

On Tue, Aug 22, 2023 at 03:00:33AM +, Russell L. Harris wrote:
> My needs are simple.  I need two git repositories.
>
> The first is my work space, into which periodically I commit the
> article on which I am working.
>
> The second repository is my backup; it resides on another machine.
> Several times a day, I SSH into the backup machine and pull the
> working repository.  It would be nice to be able to push from WORKING
> to BACKUP, eliminating the need to SSH.
>
> I cloned the WORKING repository from the old host, and the WORKING
> repository appears to function correctly.  But I do not know how to
> configure the BACKUP repository.  I tried the BARE option, but I am not
> able to push from WORKING to BACKUP.

Creating BACKUP as a bare repository, configuring it as a remote in WORKING and
pushing WORKING to BACKUP whenever you want is the correct setup for your
situation. If you can ssh to the backup machine it's weird that you can't push
to it. What happens when you use `git push`?


--
Ceppo

Re: git setup

[Sven Joachim]

On 2023-08-22 03:00 +, Russell L. Harris wrote:

> After much searching and reading, I have not discovered how to set up
> a pair of git repositories to work together.
>
> I write articles for publication.  I typically spend anywhere from
> several hours to many days on each article.  It is frustrating to work
> for an hour or two on a paragraph or a page and then accidentally to
> erase what I have written.
>
> In the past, I have found git to be a very good solution.  But now I
> am moving to a new computer, and I an having difficulty replicating
> the previous setup.
>
> My needs are simple.  I need two git repositories.
>
> The first is my work space, into which periodically I commit the
> article on which I am working.
>
> The second repository is my backup; it resides on another machine.
> Several times a day, I SSH into the backup machine and pull the
> working repository.  It would be nice to be able to push from WORKING
> to BACKUP, eliminating the need to SSH.

Git supports pushing via the ssh protocol, and since you have already
set up the ssh connection, the rest is rather simple.

> I cloned the WORKING repository from the old host, and the WORKING
> repository appears to function correctly.  But I do not know how to
> configure the BACKUP repository.  I tried the BARE option, but I am not
> able to push from WORKING to BACKUP.

On the backup machine, create a bare repository:

$ mkdir -p /path/to/backup-repo.git
$ cd /path/to/backup-repo.git
$ git init --bare

Then you can push from your work machine:

$ git push --all ssh://[user@]/path/to/backup-repo.git
$ git push --tags ssh://[user@]/path/to/backup-repo.git

where "" is the hostname of your backup machine, and "user" is
your login name there (which you can usually omit).  You probably also
want to add the backup repository as a remote, so that you do not have
to write the long URL every time you push.

Cheers,
   Sven

[SOLVED] !Re: Favicon Firefox

[Hans]

Hi folks,

found the reason, why favicons were not shown: I was my own fault!

I disabled "create chronicle" in the settings of firefox, and with doing so, 
all favicons are not shown in a new tab.

Now I reactivated it and everything is working normal.

Damn me!

Btw: The thinking was logically: Wondered, why there is no chronicle, then the 
lights in my brain lit on: No chronicle = no favicons, of course.

Happy to solved the problem.

Thanks for all, who tried to help!

Best regards

Hans 

No korganizer, kmix, akregator icon in the task bar (but yes for kwrite...)

[Carles Pina i Estany]

Hi,

Bookworm here, but the same issues (at least for korganizer) happened on
bullseye.

I'd like to ask something so I either open a bug or investigate more in
my system (or in case that anyone knows more, if someone has fixed it).

I use LXDE with some KDE applications. Some applications such as
korganizer, kmix, akregator: in the task bar I have a generic LXDE icon
(or the top-left icon if I have the application visible)

Other applications such as kcalc, kwrite or kate have the icons as
expected.

I guess that it's my problem (but it actually happens in two computers)
but I'd like to confirm it. Can, some of you, see the icons for
korganizer, akregator, in the task bar? With window manager (or panel)?

I'll investigate more but any information (works here, doesn't there)
for a couple of people might help me.

Thank you very much,

-- 
Carles Pina i Estany
https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat

Re: Disk error?

[zithro]

On 21 Aug 2023 19:53, Tim Woodall wrote:

On Mon, 21 Aug 2023, Tim Woodall wrote:


On Wed, 24 Aug 2022, Tim Woodall wrote:


I got this error while installing build-essential

Preparing to unpack .../03-libperl5.34_5.34.0-5_arm64.deb ...
Unpacking libperl5.34:arm64 (5.34.0-5) ...
dpkg-deb (subprocess): decompressing archive 
'/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb' 
(size=4015516) member 'data.tar': lzma error: compressed data is corrupt

dpkg-deb: error:  subprocess returned error exit status 2
dpkg: error processing archive 
/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb 
(--unpack):
cannot copy extracted data for 
'./usr/lib/aarch64-linux-gnu/libperl.so.5.34.0' to 
'/usr/lib/aarch64-linux-gnu/libperl.so.5.34.0.dpkg-new': unexpected 
end of file or stream


Am I right that this must be a local error - apt will have verified the
checksum while downloading the deb? (and it worked on rerunning - the
deb was in acng)

I can find nothing anywhere that suggests anything has gone wrong (other
than this error) but (and I'm sure it's a coincidence) since installing
ACNG (on the same machine) I've been getting a number of errors similar
to things like this where files appear to be corrupted but work on the
next attempt.

There's no SMART errors or anything like that either.

Anyone got any ideas - any logging I should add to try and track down
where the issue might be?

Tim.




Just a FYI, I've been battling this, and errors like this for almost a
year. The last but one kernel upgrade seems to have fixed it. :-)

I've been reverting all the changes I made trying to track it down and,
touch wood, it's not come back.

One of these two upgrades fixed it. (the first doesn't seem plausible)

Start-Date: 2023-08-11  06:25:52
Commandline: apt-get -y upgrade
Upgrade: usbip:amd64 (2.0+5.10.179-3, 2.0+5.10.179-5)
End-Date: 2023-08-11  06:25:53

Start-Date: 2023-08-12  08:16:59
Commandline: apt-get -y dist-upgrade
Install: linux-image-5.10.0-24-amd64:amd64 (5.10.179-5, automatic)
Upgrade: linux-image-amd64:amd64 (5.10.179-3, 5.10.179-5)
End-Date: 2023-08-12  08:23:07

I cannot tell which machine mattered, could be the xen host, the guest
running apt, the guest running apt-cacher-ng or the one running the
squid proxy. (the last two feel impossible given the symptoms above)

The disk was mounted via iscsi on the xen host, so it's not quite as
simple as saying apt got the right file over the network therefore it
must be the guest.

I'm not going to try to reproduce and track down exactly what fixed it.

Tim.



So I spoke too soon. Reverting the last change I made, resulting in
halving the memory and leaving only one vcpu in the guest, meaning that
the guest is severely loaded and I got a one bit error in a downloaded
(Packages.xz) file.



Some ideas :

- Are the iscsi drives served by a local domU or from remote ?
- Have you tried moving all the iscsi-backed drives on the local dom0 
filesystem ?
- Maybe the problem is with slow syncing data to source disk(s) ? (as 
you wrote "files appear to be corrupted but work on the next attempt").


[
I had a (somewhat similarly strange ?) problem trying to install Qubes 
as a domU, from an ISO served by an NFS mount from another domU, like :

domU --[NFS]--> dom0 --[use ISO on NFS mount]--> Qubes domU

The install failed with "Payload SHA256 digest: BAD", although the ISO 
file was OK (verified with sha256).
When I COPIED the same ISO (ie. no re-download) from the NFS mount to 
the dom0 local FS (ext4), the install went fine.


In both runs, the Qubes domU was using local ext4 disk images, so in my 
case only the source was giving errors, maybe error in transit ?

I didn't try more tests to discover what was causing this.
Also, it was in february 2022, so things may have changed, didn't test 
since.


For reference, the related Qubes post, although not containing much more 
info: 
https://forum.qubes-os.org/t/installation-report-payload-digest-error-for-pkg-xen-hypervisor-2001/9644

(remove bracket stuff when replying)
]

--
++
zithro / Cyril

Re: git setup

[tomas]

On Tue, Aug 22, 2023 at 09:16:47AM -0500, John Hasler wrote:
> Christoph writes:
> > I have almost the same setup and use local git repositories.  Instead
> > of syncing them by the git tools I use rsync to update the backup from
> > time to time. This is a dumb method but it works.
> 
> This is what I do as well.

Actually... not that dumb. Git tends to be very rsync-friendly. In some
weird way, this is no coincidence.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Después de actualizar no arranca «entorno gráfico» de forma automática

[Camaleón]

El 2023-08-22 a las 14:46 +0200, aa ag escribió:

> En principio, según el tutorial de Ubuntu está todo bien (a falta de probar 
> el paso de ubuntu.deskop).
> No se si esto puede dar alguna pista?
> 
> 
> Aquí dijimos que no había nada grave /var/log/lightdm/lightdm.log:
> 
> [+0.00s] DEBUG: Loading configuration dirs from 
> /usr/share/lightdm/lightdm.conf>

(...)

> Estas líneas se me pasaron por alto /var/log/Xorg.0.log:
> 
> [   139.663] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
> exist.
> [   139.745] (EE) open /dev/dri/card0: No such file or directory
> [   139.745] (WW) Falling back to old probe method for modesetting
> [   139.745] (EE) open /dev/dri/card0: No such file or directory
> [   139.746] (EE) Unable to find a valid framebuffer device
> [   139.746] (WW) Falling back to old probe method for fbdev
> [   139.746] (EE) open /dev/fb0: No such file or directory
> [   139.746] (EE) Screen 0 deleted because of no matching config section.
> [   139.746] (EE) Screen 0 deleted because of no matching config section.
> [   139.746] (EE) Screen 0 deleted because of no matching config section.
> [   139.767] (WW) VESA(0): Unable to estimate virtual size

Todos los EE (errores) de Xorg son (o pueden ser) GRAVES.
Ejecuta la siguiente orden y manda la salida:

grep -e "(EE)" -e "(WW)" /var/log/Xorg.* 

> Y este se me quedó a revisar ~/.xsession-errors:
> 

(...)

> ** (light-locker:2799): ERROR **: 03:19:08.077: Environment variable 
> XDG_SESSION_PATH not set. Is LightDM running?

Este mensaje es consecuente con el hecho de que LighDM no esté 
ejecutándose.

Vamos a centrarnos en Xorg a ver si sacamos algo útil de ahí.

Saludos,

-- 
Camaleón 

Re: git setup

[John Hasler]

Christoph writes:
> I have almost the same setup and use local git repositories.  Instead
> of syncing them by the git tools I use rsync to update the backup from
> time to time. This is a dumb method but it works.

This is what I do as well.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Michael Stone]

On Sat, Aug 19, 2023 at 09:19:48PM +0200, Christoph K. wrote:

Could you please recommend a "suitable" sans-serif font that


A lot of your criteria are rather subjective. For packaged fonts you 
might look at "hack" 
(https://source-foundry.github.io/Hack/font-specimen.html)

or "go"
(https://go.dev/blog/go-fonts)

There's also the not-packaged https://github.com/intel/intel-one-mono 


But you'd have to be the judge of what you like the look of.

Re: Después de actualizar no arranca «entorno gráfico» de forma automática

[aa ag]

En principio, según el tutorial de Ubuntu está todo bien (a falta de probar el 
paso de ubuntu.deskop).
No se si esto puede dar alguna pista?


Aquí dijimos que no había nada grave /var/log/lightdm/lightdm.log:

[+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf>
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/01>
[+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightd>
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf.d/lightdm->
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Registered seat module local
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: Using cross-namespace EXTERNAL authentication (this will deadlo>
[+0.00s] DEBUG: _g_io_module_get_default: Found default implementation local (G>
[+0.00s] DEBUG: Monitoring logind for seats
[+0.00s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: Stopping Plymouth, no displays replace it
[+0.00s] DEBUG: Quitting Plymouth
[+0.03s] WARNING: Could not enumerate user data directory /var/lib/lightdm/data>
[+29.72s] DEBUG: Seat seat0 changes active session to 1
[+129.06s] DEBUG: Seat seat0 changes active session to
[+133.28s] DEBUG: Seat seat0 changes active session to 3
 


Estas líneas se me pasaron por alto /var/log/Xorg.0.log:

[   139.663] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   139.745] (EE) open /dev/dri/card0: No such file or directory
[   139.745] (WW) Falling back to old probe method for modesetting
[   139.745] (EE) open /dev/dri/card0: No such file or directory
[   139.746] (EE) Unable to find a valid framebuffer device
[   139.746] (WW) Falling back to old probe method for fbdev
[   139.746] (EE) open /dev/fb0: No such file or directory
[   139.746] (EE) Screen 0 deleted because of no matching config section.
[   139.746] (EE) Screen 0 deleted because of no matching config section.
[   139.746] (EE) Screen 0 deleted because of no matching config section.
[   139.767] (WW) VESA(0): Unable to estimate virtual size



Y este se me quedó a revisar ~/.xsession-errors:

Xsession: X session started for a at...
dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting XAUTHORITY=/home/user/.Xauthority
localuser:a being added to access control list
dbus-update-activation-environment: setting 
XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting USER=user
dbus-update-activation-environment: setting XDG_SESSION_TYPE=x11
dbus-update-activation-environment: setting SHLVL=0
dbus-update-activation-environment: setting HOME=/home/user
dbus-update-activation-environment: setting DESKTOP_SESSION=Default Xsession
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting SYSTEMD_EXEC_PID=802
dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting LOGNAME=user
dbus-update-activation-environment: setting JOURNAL_STREAM=8:20102
dbus-update-activation-environment: setting 
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/system.slice/lxdm.service/memory.pressure
dbus-update-activation-environment: setting XDG_SESSION_CLASS=user
dbus-update-activation-environment: setting 
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
dbus-update-activation-environment: setting 
INVOCATION_ID=bb10a96f06984beab99e037003b8dcee
dbus-update-activation-environment: setting XDG_RUNTIME_DIR=/run/user/1000
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting LANG=es_ES.UTF-8
dbus-update-activation-environment: setting XAUTHORITY=/home/user/.Xauthority
dbus-update-activation-environment: setting SHELL=/bin/bash
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting 
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
dbus-update-activation-environment: setting PWD=/home/user
dbus-update-activation-environment: setting 
XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/
dbus-update-activation-environment: setting 
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
/usr/bin/x-session-manager: X server already running on display :0
/usr/bin/iceauth:  creating new authority file /run/user/1000/ICEauthority
xfce4-session-Message: 03:19:07.619: SSH authentication agent is already running
gpg-agent: ya hay un agente gpg ejecutándose - no se inicia otro

(xfwm4:2721): xfwm4-WARNING **: 

Re: UEFI op servers, of niet?

[Dennis van Dok]

On 22-08-2023 11:54, Paul van der Vlis wrote:

Hallo Dennis en anderen,

Op 22-08-2023 om 10:45 schreef Dennis van Dok:

On 15-08-2023 12:13, Paul van der Vlis wrote:


We zijn (bij Nikhef, plusminus 500 systemen) al een paar jaar helemaal 
over op EFI boot aangezien de nieuwere systemen legacy helemaal niet 
meer ondersteunen. 


Daar heb ik nog geen last van bij servers, bij welke fabrikanten zie je 
dat?


IIRC Dell en Lenovo, in combinatie met ondersteuning voor PXE boot en 
grote NVMe drives.


Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden. 


Ik ken dit eigenlijk alleen van kleinere systemen om eerlijk te zijn, 
bijvoorbeeld van Dell. Maar qua 19" systemen gebruik ik Supermicro en 
dat doet nog niet mee.  Dit is wat ik bedoel:

https://packages.debian.org/bullseye/fwupd
https://fwupd.org/


Ik ga daar nog wel eens naar kijken want het lijkt me toch wel handig om 
te automatiseren (als dat kan). En natuurlijk altijd met de Bewuste 
Keuze™ welke updates je doorvoert!


Ik gebruik in de praktijk geen software van de fabrikant, het is 
allemaal Debian.


DELL heeft racadm en dat werkt nog vrij aardig standalone, maar we 
stappen meer en meer over op redfish.


Ik heb altijd met software RAID gewerkt en zie niet veel voordelen aan 
hardware RAID. Er zijn wel voordelen, maar ook nadelen.


Voordelen van software RAID vind ik:
- Het is heel generiek, een disk past zo in een andere machine zonder 
dat die ook zo'n kaart nodig heeft.


Doe je dat dan vaak, schijven uitwisselen tussen apparaten?


- De RAID kaart kan kapot gaan, je moet eigenlijk een spare hebben.


Dit is nou een van de componenten die ik zelden tot nooit heb zien falen.


- Tools zijn vaak closed source, en complex.


We configgen die meuk direct vanuit het BIOS (of laten dat vooraf doen 
door de leverancier) of anders is het Megaraid storcli (ja, beetje 
ingewikkeld wel).


- Volgens mij moet je bij hardware RAID rebooten als je een disk wilt 
vervangen. (En misschien zelfs wachten tijdens het rebuilden.)


Al onze storage systemen doen hot-swapping dus misschien moet je een 
ander merk uitkiezen?



- Je zit directer op de disk, er zit geen kaart tussen


En wat is daarvan nou het specifieke voordeel?


- Reuze veel mogelijkheden


Ben ook benieuwd!


Nadelen van software RAID vind ik:


- Niet geschikt voor systemen met heel veel disks (in elk geval was dat 
vroeger zo).


Ik weet dat we ook wel eens een wat grotere software raid setup hebben 
gedraaid (in de speeltuin) en dat werkte ook prima.



Voor zover ik weet is het een niet echt sneller dan het ander, maar 
misschien vergis ik me daarin.


Nee, dat zal ook niet het argument zijn. Er zijn trouwens behoorlijke 
kwaliteitsverschillen in hardware raid.


De EFI partitie moet leesbaar zijn voor de firmware. Met hardware RAID 
is dat volgens mij geen probleem, maar het komt me voor dat de BIOS 
niet snapt wat een software raid partitie is. 


Dat snappen ze inderdaad niet, maar ze kunnen het volgens mij wel gewoon 
lezen en booten. Dat doen ze dan van de individule disk, niet van de RAID.


Ja, legacy boot van een bootsector zal wel gaan denk ik. En misschien is 
een moderne grub ook al software raid aware?


Als ze erop schrijven (ik weet niet zeker of ze dat weleens doen), 
zullen ze ook op de disk schrijven en niet op de RAID.


Dat zouden ze nooit moeten doen!



Misschien is een los klein SSD'tje dan een idee? Een andere 
mogelijkheid is om op één schijf de EFI partitie te maken en op de 
andere dezelfde ruimte te benutten als swap ofzo. Dan houd je de 
geometrie op de resterende ruimte over voor software raid 1.


Mijn punt is dat dit een single point of failure is. Bij software RAID 
kan ik met IPMI in het bios de bootdisk wijzigen, en dan boot hij weer. 
Of fysiek de disks wisselen.


De vraag is of je gaat voor data security (dus hoe belangrijk vind je 
het dat je geen data verliest) of voor uptime (hoe belangrijk is het om 
beschikbaar te zijn). Voor beide kun je plannen maar het prijskaartje 
wordt natuurlijk ook steeds hoger.

Re: UEFI op servers, of niet?

[Paul van der Vlis]

Hallo Dennis en anderen,

Op 22-08-2023 om 10:45 schreef Dennis van Dok:

On 15-08-2023 12:13, Paul van der Vlis wrote:

Hallo,

Wat is jullie mening over UEFI?  Ik vind het nogal een complex 
gebeuren waarbij aardig wat dingen mee mis kunnen gaan. En wellicht 
ook minder veilig dan "legacy".


Niet per se, maar moderne systemen hebben steeds meer management aan 
boord die op zich weer een aanvalsvector kan vormen. Het beangstigendste 
daarbij is hoezeer deze verweven zijn met het systeem, onder het OS 
niveau. Dus aanvallen om private keys uit het geheugen te vissen zonder 
dat je dat in het OS in de gaten hebt bijvoorbeeld.


Inderdaad.

We zijn (bij Nikhef, plusminus 500 systemen) al een paar jaar helemaal 
over op EFI boot aangezien de nieuwere systemen legacy helemaal niet 
meer ondersteunen. 


Daar heb ik nog geen last van bij servers, bij welke fabrikanten zie je dat?

Met netboot en grub-efi werkt bijna alles als 
voorheen, en ik zie de boot manager zelfs wel as een pre. Maar inderdaad 
is het vooral een kwestie van de kernel booten en dat is het.


Het feit dat er vrij automatisch firmware wordt geïnstalleerd van de 
fabrikant vind ik niet prettig. Maar dit is vast uit te zetten ;-)


Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden. 


Ik ken dit eigenlijk alleen van kleinere systemen om eerlijk te zijn, 
bijvoorbeeld van Dell. Maar qua 19" systemen gebruik ik Supermicro en 
dat doet nog niet mee.  Dit is wat ik bedoel:

https://packages.debian.org/bullseye/fwupd
https://fwupd.org/

Hoewel $VENDOR1 een systeem biedt om dat te automatiseren gebruiken wij 
dat liever niet want dan zit je daaraan vast, terwijl we ook spullen van 
$VENDOR2 willen kunnen kopen en gebruiken.


Ik gebruik in de praktijk geen software van de fabrikant, het is 
allemaal Debian.


Het enige voorbeeld wat me te binnen schiet zijn de 'intelligente' 
lampen die je met een app kunt dimmen. Die deden het niet meer toen ik 
hun internettoegang uitschakelde.


Dat soort dingen heb ik graag lokaal geregeld ;-)

Ik wil graag dat alles op RAID1 komt (mdadm, maar ook alternatieven 
zijn bespreekbaar), en het liefst ook op LVM of soortgelijk.


Wees dapper en die RAID0 all the way. (geintje). Volgens mij ondersteund 
de Debian installer dit wel. Als je een redelijke RAID kaart hebt kun je 
het beter aan de hardware overlaten, lijkt me.


Ik heb altijd met software RAID gewerkt en zie niet veel voordelen aan 
hardware RAID. Er zijn wel voordelen, maar ook nadelen.


Voordelen van software RAID vind ik:
- Het is heel generiek, een disk past zo in een andere machine zonder 
dat die ook zo'n kaart nodig heeft.

- De RAID kaart kan kapot gaan, je moet eigenlijk een spare hebben.
- Tools zijn vaak closed source, en complex.
- Volgens mij moet je bij hardware RAID rebooten als je een disk wilt 
vervangen. (En misschien zelfs wachten tijdens het rebuilden.)

- Je zit directer op de disk, er zit geen kaart tussen
- Reuze veel mogelijkheden

Nadelen van software RAID vind ik:
- Defecte disk verwisselen is iets lastiger
- Als de boot-disk defect is, wil het systeem soms niet meer booten 
zonder andere actie zoals het bios aanpassen of disks verwisselen
- Inrichten (en wellicht bijhouden) is ingewikkelder, je moet 
bijvoorbeeld Grub twee keer installeren, en wellicht EFI kopieren.
- Niet geschikt voor systemen met heel veel disks (in elk geval was dat 
vroeger zo).


Voor zover ik weet is het een niet echt sneller dan het ander, maar 
misschien vergis ik me daarin.


Als je veel systemen hebt met allemaal dezelfde hardware RAID, ziet het 
plaatje er misschien iets anders uit.


Ik heb nog geen ervaring om de EFI partitie op mdadm RAID1 te zetten, 
maar misschien dat het wel kan.  Wat ik in de praktijk doe is de 
partitie kopiëren naar de andere disk met dd.


De EFI partitie moet leesbaar zijn voor de firmware. Met hardware RAID 
is dat volgens mij geen probleem, maar het komt me voor dat de BIOS niet 
snapt wat een software raid partitie is. 


Dat snappen ze inderdaad niet, maar ze kunnen het volgens mij wel gewoon 
lezen en booten. Dat doen ze dan van de individule disk, niet van de RAID.


Als ze erop schrijven (ik weet niet zeker of ze dat weleens doen), 
zullen ze ook op de disk schrijven en niet op de RAID.


Misschien is een los klein 
SSD'tje dan een idee? Een andere mogelijkheid is om op één schijf de EFI 
partitie te maken en op de andere dezelfde ruimte te benutten als swap 
ofzo. Dan houd je de geometrie op de resterende ruimte over voor 
software raid 1.


Mijn punt is dat dit een single point of failure is. Bij software RAID 
kan ik met IPMI in het bios de bootdisk wijzigen, en dan boot hij weer. 
Of fysiek de disks wisselen.


Dit is overigens wel complexer dan bij hardware RAID. Jammer dat er geen 
biossen zijn (voor zover ik weet) die dit netjes oplossen (zonder fakeraid).



Ik denk dat LVM het native ook kan maar dat heb ik nooit geprobeerd.



Ook grote disks kunnen ook zonder EFI, maar dan is er een 

Re: upgrade to bookworm broke phpmyadmin

[Michael Kjörling]

On 21 Aug 2023 20:00 -0600, from rickm...@shaw.ca (Rick Macdonald):
>> # dpkg-reconfigure phpmyadmin
>> Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
>> dbconfig-common: writing config to /etc/dbconfig-common/phpmyadmin.conf
>> dbconfig-common: flushing administrative password
>> apache2_invoke phpmyadmin: already enabled

$ dpkg -l php php8.2 phpmyadmin

Which exact version of each respective package is installed?

Also

$ aptitude why php8.2

_IF_ the version of phpmyadmin which Bookworm ships doesn't work with
the version of PHP which Bookworm ships, that's at a minimum a
packaging bug. But that would be an awfully obvious one that a lot
more people should already have run into in that case, so I'm
reluctant to assume that that's the problem. I'm more inclined to
believe that maybe you're somehow running a non-Bookworm version of
phpmyadmin which for whatever reason doesn't work with PHP 8, or for
some reason your installation of phpmyadmin is being run through a
different version of PHP. Buster and Bullseye were both PHP 7.x; which
could help explain why it worked there but not after you upgraded to
Bookworm.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: UEFI op servers, of niet?

[Dennis van Dok]

On 15-08-2023 12:13, Paul van der Vlis wrote:

Hallo,

Wat is jullie mening over UEFI?  Ik vind het nogal een complex gebeuren 
waarbij aardig wat dingen mee mis kunnen gaan. En wellicht ook minder 
veilig dan "legacy".


Niet per se, maar moderne systemen hebben steeds meer management aan 
boord die op zich weer een aanvalsvector kan vormen. Het beangstigendste 
daarbij is hoezeer deze verweven zijn met het systeem, onder het OS 
niveau. Dus aanvallen om private keys uit het geheugen te vissen zonder 
dat je dat in het OS in de gaten hebt bijvoorbeeld.


We zijn (bij Nikhef, plusminus 500 systemen) al een paar jaar helemaal 
over op EFI boot aangezien de nieuwere systemen legacy helemaal niet 
meer ondersteunen. Met netboot en grub-efi werkt bijna alles als 
voorheen, en ik zie de boot manager zelfs wel as een pre. Maar inderdaad 
is het vooral een kwestie van de kernel booten en dat is het.


Het feit dat er vrij automatisch firmware wordt geïnstalleerd van de 
fabrikant vind ik niet prettig. Maar dit is vast uit te zetten ;-)


Welke systemen doen dit? Wij moeten altijd zelf onze firmware bijhouden. 
Hoewel $VENDOR1 een systeem biedt om dat te automatiseren gebruiken wij 
dat liever niet want dan zit je daaraan vast, terwijl we ook spullen van 
$VENDOR2 willen kunnen kopen en gebruiken.


Het enige voorbeeld wat me te binnen schiet zijn de 'intelligente' 
lampen die je met een app kunt dimmen. Die deden het niet meer toen ik 
hun internettoegang uitschakelde.


Ik wil graag dat alles op RAID1 komt (mdadm, maar ook alternatieven zijn 
bespreekbaar), en het liefst ook op LVM of soortgelijk.


Wees dapper en die RAID0 all the way. (geintje). Volgens mij ondersteund 
de Debian installer dit wel. Als je een redelijke RAID kaart hebt kun je 
het beter aan de hardware overlaten, lijkt me.


Ik heb nog geen ervaring om de EFI partitie op mdadm RAID1 te zetten, 
maar misschien dat het wel kan.  Wat ik in de praktijk doe is de 
partitie kopiëren naar de andere disk met dd.


De EFI partitie moet leesbaar zijn voor de firmware. Met hardware RAID 
is dat volgens mij geen probleem, maar het komt me voor dat de BIOS niet 
snapt wat een software raid partitie is. Misschien is een los klein 
SSD'tje dan een idee? Een andere mogelijkheid is om op één schijf de EFI 
partitie te maken en op de andere dezelfde ruimte te benutten als swap 
ofzo. Dan houd je de geometrie op de resterende ruimte over voor 
software raid 1.


Ik denk dat LVM het native ook kan maar dat heb ik nooit geprobeerd.


Ook grote disks kunnen ook zonder EFI, maar dan is er een BIOS BOOT 
partitie nodig. Ik weet niet goed of dat op RAID1 kan.


Nee om dezelfde reden als hierboven (tenzij hardware RAID).

Ik zag overigens ook iemand die mdadm gebruikte op de hele schijf, dus 
niet op partities. Ik had problemen om in de rescue-mode van de 
debian-installer de RAID5 te maken (er was een disk defect). Wat vinden 
jullie van deze constructie?  Zal dit ook b.v. de boot-sector en 
partitie-tabel automatisch in de RAID opnemen?


We hebben voor storage systemen eigenlijk altijd een losse SSD voor het 
OS. Het klinkt als een nodeloos ingewikkelde constructie en vragen om 
moeilijkheden.


Dennis

Re: git setup

[john doe]

On 8/22/23 05:00, Russell L. Harris wrote:

After much searching and reading, I have not discovered how to set up
a pair of git repositories to work together.


This makes no sense, that is what Git is for! :)



In the past, I have found git to be a very good solution.  But now I
am moving to a new computer, and I an having difficulty replicating
the previous setup.



Rethinking your set up, might not be a bad idea!


My needs are simple.  I need two git repositories.



Basically, Git uses non-bare/mirror repository (you work in this one)
and an upstream repo which will be 'bare'.


The first is my work space, into which periodically I commit the
article on which I am working.



I'm OK so far!


The second repository is my backup; it resides on another machine.
Several times a day, I SSH into the backup machine and pull the
working repository.



To me you only update upstream by pushes and never by pulling!

So my suggestion in your case would be:
- One repo to work in and to push to upstream
- One upstream bare repo

If you want a working  repo on the same box as the bare repo is located,
use  the file protocol to pull using a cron job for automation!

HTH.

--
John Doe

Re: git setup

[Christoph Brinkhaus]

Am Tue, Aug 22, 2023 at 03:00:33AM + schrieb Russell L. Harris:
Hello Russel,
I cannot answer your question directly but show what I am doing now.

> After much searching and reading, I have not discovered how to set up
> a pair of git repositories to work together.
> 
> I write articles for publication.  I typically spend anywhere from
> several hours to many days on each article.  It is frustrating to work
> for an hour or two on a paragraph or a page and then accidentally to
> erase what I have written.
> 
> In the past, I have found git to be a very good solution.  But now I
> am moving to a new computer, and I an having difficulty replicating
> the previous setup.
> 
> My needs are simple.  I need two git repositories.
> 
> The first is my work space, into which periodically I commit the
> article on which I am working.
> 
> The second repository is my backup; it resides on another machine.
> Several times a day, I SSH into the backup machine and pull the
> working repository.  It would be nice to be able to push from WORKING
> to BACKUP, eliminating the need to SSH.

I have almost the same setup and use local git repositories.
Instead of syncing them by the git tools I use rsync to update the
backup from time to time. This is a dumb method but it works.

> I cloned the WORKING repository from the old host, and the WORKING
> repository appears to function correctly.  But I do not know how to
> configure the BACKUP repository.  I tried the BARE option, but I am not
> able to push from WORKING to BACKUP.

To dig that is on my todo list as well. But as an additional backup I
would run the dump method in parallel, just in case I manage to screw up
the git repository.

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.


signature.asc
Description: PGP signature

Re: mailx and selinux not co-operating

[Bhasker C V]

For future reference

There is another package mailutils which also provides /usr/bin/mail.
This is working fine with selinux in enforcing mode.
This is a good alternative



On Mon, Aug 21, 2023 at 2:56 AM Bhasker C V  wrote:

> Thanks Nicholas
> However, it doesnt  to my knowledge looks like an issue with mailx or
> sendmail (I use exim4).
> The reason i derive at at is because the whole thing works the moment i
> disable selinux.
>
> What i wonder is why selinux is not complaining about the failure ? No
> logs whatsoever ...
>
> On Mon, Aug 21, 2023 at 12:58 AM Nicholas Geovanis 
> wrote:
>
>> On Sun, Aug 20, 2023, 9:20 AM Bhasker C V  wrote:
>>
>>> Finally i switched on the enforcing mode on my linux system
>>> Pretty much everything is working except
>>>
>>> ```
>>> $ echo hello | mail -s test x...@yyy.xyz
>>> 2023-08-20 14:39:30 1qXieQ-000Bpa-1P 1qXieQ-000Bpa-1P no recipients
>>> found in headers
>>> Can't send mail: sendmail process failed with error code 1
>>> ```
>>> however the same works fine when I put selinux in permissive state (no
>>> warnings shown in audit/dmesg)
>>>
>>
>> Is it easy for you to get the headers that cause Sendmail to say "no
>> recipients found in headers"? And compare with the headers generated by the
>> successful mail.
>> It might help tell if it's a bug or working as designed ;-) or maybe a
>> mailx issue not sendmail.
>>
>> A quick ltrace says
>>> ```
>>>  1qXia0-000BPb-0a Failed to create spool file
>>> /var/spool/exim4//input//1qXia0-000BPb-0a-D: Permission denied
>>> ```
>>>
>>> However there are no avc: messages for me to allow this through in my
>>> selinux module
>>> I even tried
>>>
>>> ```
>>> allow unconfined_t exim_spool_t:file { open read write create };
>>> allow unconfined_t exim_spool_t:dir { open read write };
>>> ```
>>>
>>> since /var/spool/exim4/input has exim_spool_dir set in it
>>>
>>> I cant fine any booleans either ..
>>>
>>> Please could someone tell me how to get this to work ? has anyone got
>>> mailx working with selinux on their system ?
>>>
>>>
>>>