Re: Kali Linux installation failure on VirtualBox

[Keith Bainbridge]

On 10/5/20 1:24 pm, Harry Brown wrote:

Hey guys,

I'm having a bit of an issue here while installing KaliLinux and I was 
wondering if you guys can help out.


I installed *Oracle VirtualBox* on my *Windows 10* and downloaded *Kali 
Linux 64bit ISO file*, Then I created a new virtual machine *(Debian 
64bit)*and started installing KaliLinux.
Everything was great and almost 5GB of packages were downloaded and 
installed, the final step is to reboot so KaliLinux can run.
I clicked on Finish Installation (after all packages and files were 
installed ) and it showed me a message saying that Kali will run after 
the machine reboot.


Guess what! *The machine rebooted and it took me back to the first 
installation page again*, I didn't know what happened or if I did 
something wrong so I clicked "Install" again and followed the steps.
And I had to wait **again for the 5GB of packages to be downloaded and 
installed ( which was frustrating ).
Installation was finished and the machine rebooted and nothing happened. 
*it took me back to the first installation page once again.*

*
*
I know it's a long email (sorry about that), But I needed to make sure 
that you guys are fully aware of what's the issue so you can help.


Thanks in advance,

HB.




Good afternoon Harry

I sometimes have to go into the settings for the virtual device and 
untick the other boot options - CD and floppy from memory.


--
Keith Bainbridge

ke1th3...@zoho.com
+61 (0)447 667 468

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Charles Curley]

On Sat, 09 May 2020 20:05:48 -0700
"Rick Thomas"  wrote:

> Filesystem  Type  Size  Used Avail Use% Mounted on
> /dev/mapper/debian--vg-root ext4   30G  9.9G   19G  36% /
> /dev/sda2   ext2  248M   78M  158M  34% /boot

Odd. That should be good for more than three kernels. I have:

root@jhegaala:~# df /boot/
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda5   226M   92M  119M  44% /boot
root@jhegaala:~#

with three kernels.

My /boot is ext4, but I doubt that makes enough difference to matter.
My installation is not EFI. Would that make the difference?

-- 
Does anybody read signatures any more?

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

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[The Wanderer]

On 2020-05-09 at 23:36, Andy Smith wrote:

> Hi Rick,
> 
> On Sat, May 09, 2020 at 08:05:48PM -0700, Rick Thomas wrote:
>> What's the best way to increase the size of /boot ?
> 
> There is no easy way. If you boot into a live/rescue environment and 
> run parted you *may* be able to shrink your LVM and grow your /boot 
> but it's a procedure fraught with danger; make sure you have 
> excellent backups first.
> 
> I am not 100% sure that parted can handle partitions that are used as
> LVM PVs.
> 
>> I can easily create a gig or so of space by a shrink/resize of
>> /home, but how do I add that space to /dev/sda2 ?
> 
> This won't work because your /home is an LVM logical volume. Its 
> actual extents could be all over sda3.
> 
>> I can't just move up the end of /dev/sda2 = start of /dev/sda3
>> without backing up and restoring, can I?
> 
> parted can move partitions about, so if you run it from outside your 
> install and it does support LVM PV then it might work. You'd 
> basically have to shift everything up the disk, making your PV (sda3)
> slightly smaller in the process.
> 
> I really wouldn't like to try it myself. With the backup that you'll 
> need you may as well just reinstall as even if parted can do this it 
> will take some time for it to rewrite all that data.

In theory I *think* it should be possible to shrink /home, shrink the
LV, shrink the PV, then expand /boot - but the practice may be quite
different from the theory.

https://unix.stackexchange.com/questions/479545/how-to-shrink-a-physical-volume
has detailed instructions on how to do one part of the process, and
indicates that gparted can indeed handle LVM PVs - but whether it's
suitable for the actual scenario at hand here probably depends on how
you've got your PVs and LVs set up, and I don't know enough about that
to make a recommendation, aside from being very careful with backups no
matter what.

(I'm also up late, so don't necessarily trust me to have things right at
the moment; double-check before going ahead, and if in doubt, don't.)

> This is a great example of why it's not good to be stingy with the 
> size of /boot.

Definitely. My current system started out with around 4-8 TB of usable
space (across all partitions, after RAID overhead) when I first built
it, and I have fully 22GB allocated to /boot. That's ridiculous overkill
- even 1GB would probably have been more than I'm likely to ever need
here, and 2GB would definitely have - but I'd far rather have erred on
the side of too much than too little.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Andy Smith]

Another thought that is maybe a little outside the box: If your BIOS
supports booting from USB or media slot then you could maybe make a
new boot partition on one of those devices and switch to booting
from that from now on.

Ties up a USB or media slot forever of course, but possibly an
acceptable compromise.

Cheers,
Andy

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

Re: Hmmm... /boot is too small. what's the best way to increase it's size?

[Andy Smith]

Hi Rick,

On Sat, May 09, 2020 at 08:05:48PM -0700, Rick Thomas wrote:
> What's the best way to increase the size of /boot ?

There is no easy way. If you boot into a live/rescue environment and
run parted you *may* be able to shrink your LVM and grow your /boot
but it's a procedure fraught with danger; make sure you have
excellent backups first.

I am not 100% sure that parted can handle partitions that are used
as LVM PVs.

> I can easily create a gig or so of space by a shrink/resize of /home, but how 
> do I add that space to /dev/sda2 ?

This won't work because your /home is an LVM logical volume. Its
actual extents could be all over sda3.

> I can't just move up the end of /dev/sda2 = start of /dev/sda3 without 
> backing up and restoring, can I?

parted can move partitions about, so if you run it from outside your
install and it does support LVM PV then it might work. You'd
basically have to shift everything up the disk, making your PV
(sda3) slightly smaller in the process.

I really wouldn't like to try it myself. With the backup that you'll
need you may as well just reinstall as even if parted can do this it
will take some time for it to rewrite all that data.

This is a great example of why it's not good to be stingy with the
size of /boot.

Cheers,
Andy

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

Kali Linux installation failure on VirtualBox

[Harry Brown]

Hey guys,


I'm having a bit of an issue here while installing Kali Linux and I was 
wondering if you guys can help out.


I installed Oracle VirtualBox on my Windows 10 and downloaded Kali Linux 64bit 
ISO file, Then I created a new virtual machine (Debian 64bit)  and started 
installing Kali Linux.
Everything was great and almost 5GB of packages were downloaded and installed, 
the final step is to reboot so Kali Linux can run.
I clicked on Finish Installation (after all packages and files were installed ) 
and it showed me a message saying that Kali will run after the machine reboot.


Guess what!  The machine rebooted and it took me back to the first installation page 
again, I didn't know what happened or if I did something wrong so I clicked 
"Install" again and followed the steps.
And I had to wait again for the 5GB of packages to be downloaded and installed 
( which was frustrating ).
Installation was finished and the machine rebooted and nothing happened. it 
took me back to the first installation page once again.


I know it's a long email (sorry about that), But I needed to make sure that you 
guys are fully aware of what's the issue so you can help.


Thanks in advance, 


HB.

Hmmm... /boot is too small. what's the best way to increase it's size?

[Rick Thomas]

I recently did a "apt update ; apt upgrade" and it died for lack of space in 
/boot when trying to install the latest kernel.

I purged a couple of old kernel packages (still present in the 'stable' repo, 
so they weren't obsolete) to make enough space and tried again.  Worked this 
time, but I would have liked to have the old kernels around as fallbacks just 
in case of a regression...

Here's the disk layout:

rbthomas@milli:~$ lsblk
NAME  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda 8:00 111.8G  0 disk 
├─sda1  8:10   512M  0 part /boot/efi
├─sda2  8:20   244M  0 part /boot
└─sda3  8:30 111.1G  0 part 
  ├─debian--vg-root   253:0028G  0 lvm  /
  ├─debian--vg-swap_1 253:10   7.9G  0 lvm  [SWAP]
  └─debian--vg-home   253:20  75.2G  0 lvm  /home
sdb 8:16   1   239G  0 disk 
└─sdb1  8:17   1   239G  0 part /media/rbthomas/Spare
mmcblk0   179:00 238.3G  0 disk 
└─mmcblk0p1   179:10 238.3G  0 part /media/rbthomas/Downloads
rbthomas@milli:~$ 

rbthomas@milli:~$ df -HTP | grep -v tmpfs
Filesystem  Type  Size  Used Avail Use% Mounted on
/dev/mapper/debian--vg-root ext4   30G  9.9G   19G  36% /
/dev/sda2   ext2  248M   78M  158M  34% /boot
/dev/sda1   vfat  536M  144k  536M   1% /boot/efi
/dev/mapper/debian--vg-home ext4   79G  4.4G   71G   6% /home
/dev/sdb1   ext4  252G   63M  239G   1% 
/media/rbthomas/Spare
/dev/mmcblk0p1  ext4  251G   63M  238G   1% 
/media/rbthomas/Downloads
rbthomas@milli:~$ 


What's the best way to increase the size of /boot ?

I can easily create a gig or so of space by a shrink/resize of /home, but how 
do I add that space to /dev/sda2 ?

I can't just move up the end of /dev/sda2 = start of /dev/sda3 without backing 
up and restoring, can I?


Any suggestions would be appreciated.
Rick

Re: advisable to use installer script?

[Celejar]

On Sat, 9 May 2020 08:00:54 +0300
Andrei POPESCU  wrote:

> On Vi, 08 mai 20, 11:31:13, Celejar wrote:
> > 
> > Indeed. It's just not clear to me that a typical package in Debian will
> > have fewer bugs than the same software downloaded straight from
> > upstream.
> 
> The main "selling" point for Debian is that the software is properly 
> integrated with the rest of the system and easy to upgrade, even between 
> releases.

Oh, absolutely - that's one of the things I love about our OS. I
was referring to general bugs in the software itself, though, and not
those having to do with upgradeability or integration with other
packages.

Celejar

Re: saving the xfce desktop background, including color gradients on the sides

[Dan Hitt]

On Sat, May 9, 2020 at 1:53 PM Cindy Sue Causey 
wrote:

> On 5/9/20, Dan Hitt  wrote:
> > With the xfce desktop, there's an application that lets you set the
> desktop
> > background.
> >
> > Applications > Settings > Desktop
> >
> > In the "Background" tab, it lets you set a few items, including a Style,
> > such as "Scaled", a Color, such as "Horizontal gradient", as well as a
> > picture that goes in the center of the desktop, with a couple of colors
> for
> > the left and right, or top and down, depending on the aspect ratio of the
> > desktop and the aspect ratio of the picture.
> >
> > I would like some way to save the settings, because sometimes it's tricky
> > to get the colors just right.  If i could save the settings, then i could
> > change the picture and the colors, and then at some time in the future,
> > revert to just what i had before.
> >
> > Perhaps it would be possible to take a screenshot and use it, but that is
> > less desirable because the information is not in any parsed form (so,
> e.g.,
> > you could not tweak the panels to the left and right of the image, as
> they
> > would be frozen by a screen shot).
> >
> > I guess i could keep a text file and copy all the settings to it,
> including
> > the color names as  6 character strings like D3D5D0.
> >
> > Is there some better way to save the background info?
>
>
> I found a start, if nothing else! 'Cause I certainly "feel your pain"
> on finding a perfect custom match that needs saved... for posterity.
> :)
>
> I changed mine then ran grep on ".* -r". This is what I got:
>
> .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml
>
> You could make your changes then save a backup copy of that XML file
> somewhere, even there in that same directory *IF* you trust you'll
> never accidentally delete those.. *NOT* hidden files. Ask tomas, I
> think it was, who once explained why they're not really "hidden", per
> se..
>
> I did see some fields for colors so here's hoping it's an all-in-one
> package, which it really should be based on its name.
>
> Cindy :)
> --
> Cindy-Sue Causey
> Talking Rock, Pickens County, Georgia, USA
>
> * runs with... a FROST ADVISORY in the middle of May?! runs... and
> covers up the pretty green bouncing baby grapevines. *
>
>
Awesome, thanks Cindy!

I think this will work perfectly for my need.

dan

Re: saving the xfce desktop background, including color gradients on the sides

[Cindy Sue Causey]

On 5/9/20, Dan Hitt  wrote:
> With the xfce desktop, there's an application that lets you set the desktop
> background.
>
> Applications > Settings > Desktop
>
> In the "Background" tab, it lets you set a few items, including a Style,
> such as "Scaled", a Color, such as "Horizontal gradient", as well as a
> picture that goes in the center of the desktop, with a couple of colors for
> the left and right, or top and down, depending on the aspect ratio of the
> desktop and the aspect ratio of the picture.
>
> I would like some way to save the settings, because sometimes it's tricky
> to get the colors just right.  If i could save the settings, then i could
> change the picture and the colors, and then at some time in the future,
> revert to just what i had before.
>
> Perhaps it would be possible to take a screenshot and use it, but that is
> less desirable because the information is not in any parsed form (so, e.g.,
> you could not tweak the panels to the left and right of the image, as they
> would be frozen by a screen shot).
>
> I guess i could keep a text file and copy all the settings to it, including
> the color names as  6 character strings like D3D5D0.
>
> Is there some better way to save the background info?


I found a start, if nothing else! 'Cause I certainly "feel your pain"
on finding a perfect custom match that needs saved... for posterity.
:)

I changed mine then ran grep on ".* -r". This is what I got:

.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml

You could make your changes then save a backup copy of that XML file
somewhere, even there in that same directory *IF* you trust you'll
never accidentally delete those.. *NOT* hidden files. Ask tomas, I
think it was, who once explained why they're not really "hidden", per
se..

I did see some fields for colors so here's hoping it's an all-in-one
package, which it really should be based on its name.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with... a FROST ADVISORY in the middle of May?! runs... and
covers up the pretty green bouncing baby grapevines. *

saving the xfce desktop background, including color gradients on the sides

[Dan Hitt]

With the xfce desktop, there's an application that lets you set the desktop
background.

Applications > Settings > Desktop

In the "Background" tab, it lets you set a few items, including a Style,
such as "Scaled", a Color, such as "Horizontal gradient", as well as a
picture that goes in the center of the desktop, with a couple of colors for
the left and right, or top and down, depending on the aspect ratio of the
desktop and the aspect ratio of the picture.

I would like some way to save the settings, because sometimes it's tricky
to get the colors just right.  If i could save the settings, then i could
change the picture and the colors, and then at some time in the future,
revert to just what i had before.

Perhaps it would be possible to take a screenshot and use it, but that is
less desirable because the information is not in any parsed form (so, e.g.,
you could not tweak the panels to the left and right of the image, as they
would be frozen by a screen shot).

I guess i could keep a text file and copy all the settings to it, including
the color names as  6 character strings like D3D5D0.

Is there some better way to save the background info?

TIA for any info!

dan

Re: ajuda amb problema amb audio (pulseaudio?)

[Àlex]

El 9/5/20 a les 16:33, Antoni Villalonga ha escrit:
> On Sat, May 9, 2020 at 8:05 AM Àlex wrote:
>> Benvolguts/des,
>>
>> Sabeu si hi ha alguna mena d'arxiu històric de nuclis de Linux?
>>
>> Per exemple, aquests últims dies Debian Testing ha actualitzat a nucli
>> 5.6, però existeix algún lloc on encara es pugui descarregar el packet
>> d'un nucli anterior: 5.5 , 5.2 , etc ? o toca descarregar les fonts a
>> kernel.org i compilar el nucli que vull recuperar?
> Aquí pots trobar tots els paquets dels ultims anys de Debian:
>   https://snapshot.debian.org/
>
> Per exemple, pots afegir aquestes linies al /etc/apt/sources.list
> deb [check-valid-until=no]
> https://snapshot.debian.org/archive/debian/20190604T00Z/ sid main
> deb-src [check-valid-until=no]
> https://snapshot.debian.org/archive/debian/20190604T00Z/ sid main
>
>
>

Just el que buscava.

Sou uns cracks

Gràcies


   Àlex

Re: Re: Mouse awfully slow on Debian 10 on certain machines

[Jörg Kampmann]

Hello list, I did some further research. In particular I used the 
live-ISO-image of Buster (amd64) on DVD and bootet the system. And I 
found the following:


Mouse still is irrational. It works fine, when no application has 
startet after logging. When then an application is started (in this case 
firefox of the DVD) the mouse mostly does not move. It jumps. And when 
there is a button something similar, the mouse behaves even worse. I did 
not dig into the "InputClass" because I did not find it.


So any help is urgently needed.

tia

Jörg

Re: Should I enable "testing"

[Peter Ehlert]

On 5/9/20 4:30 AM, Brian wrote:

On Sat 09 May 2020 at 12:12:08 +0200, Jean-Philippe MENGUAL wrote:
  

Le 09/05/2020 à 09:44, J.Arun Mani a écrit :




No, would be impossible and catastrophic. Either re-install, or try testing
now, could be good for you. Reverting a such big upgrade is impossible (or
very difficult and unsafe)

Staying on bullseye is not likely to be such a disastrous move.

agreed.
I goofed a couple years ago. I intended to just grab a couple "newer" 
packages, but did not understand what I had actually done (migrated to 
Testing)
Being Lazy I continued using it. There were a few glitches, some things 
broke, but usually in about 6 to 8 hours another update fixed it.

It was OK, but annoying.

A month or so ago I did a full fresh reinstall. Life is Sweet! ... no 
more futzing around!

Personal choice.

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[Sébastien NOBILI]

Le 2020-05-09 15:17, G2PC a écrit :

Ce qui nous donne, pour le moment, deux script différents, un que
j'utilise manuellement, un second qui serait à lancer via la crontab
de root.
Je me trompe, ou, ils ne seront pas pareil, du fait de l'approche avec
root, qui serait différente que dans le cas d'un utilisateur normal
mais en sudoers ?


Je n'ai pas regardé en détail la différence entre les deux, mais je 
pense

que tu fais fausse route. Peu importe la façon dont il va être lancé, il
est préférable de n'avoir qu'un seul script (qui pourra éventuellement
s'adapter à son contexte d'exécution).

Là encore, il arrivera sûrement un jour où tu feras une modification 
dans

l'un et que tu oublieras de reporter dans l'autre et ce sera le drame.

Sébastien

Re: ajuda amb problema amb audio (pulseaudio?)

[Antoni Villalonga]

On Sat, May 9, 2020 at 8:05 AM Àlex wrote:
>
> Benvolguts/des,
>
> Sabeu si hi ha alguna mena d'arxiu històric de nuclis de Linux?
>
> Per exemple, aquests últims dies Debian Testing ha actualitzat a nucli
> 5.6, però existeix algún lloc on encara es pugui descarregar el packet
> d'un nucli anterior: 5.5 , 5.2 , etc ? o toca descarregar les fonts a
> kernel.org i compilar el nucli que vull recuperar?

Aquí pots trobar tots els paquets dels ultims anys de Debian:
  https://snapshot.debian.org/

Per exemple, pots afegir aquestes linies al /etc/apt/sources.list
deb [check-valid-until=no]
https://snapshot.debian.org/archive/debian/20190604T00Z/ sid main
deb-src [check-valid-until=no]
https://snapshot.debian.org/archive/debian/20190604T00Z/ sid main



-- 

Antoni Villalonga i Noceras
#Bloc# ~> http://friki.cat/
#Twitter# ~> @friki

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[G2PC]

> Je privilégierais ça :
>
>     sudo cp /etc/hosts.deny /etc/hosts.deny.bak
>
> Tu devrais interrompre ici si wget n'aboutit pas :
>
>     wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
>
>>  cat /tmp/superhosts.deny > /etc/hosts.deny
>
> Chevron simple (">") plutôt non ? tu veux remplacer le contenu plutôt que
> l'ajouter à la suite (si j'ai bien suivi)…

Point 1 et 2 ok. Point 3, effectivement, initialement, je déplaçais le
fichier hosts.deny et il n'existait plus un court instant.
Ce qui nous donne, pour le moment, deux script différents, un que
j'utilise manuellement, un second qui serait à lancer via la crontab de
root.
Je me trompe, ou, ils ne seront pas pareil, du fait de l'approche avec
root, qui serait différente que dans le cas d'un utilisateur normal mais
en sudoers ?

En fait, je pense me tromper, car, même dans le script que je pense
comme " normal ", il est lancé par sudoers, donc, je dois également
définir le moment ou il faut utiliser le simple utilisateur pour
télécharger.

Par contre, j'ai un gros doute sur la fin du deuxième script, j'ai mis
deux fois exit, la première fois pour quitter l'utilisateur sur lequel
j'ai basculé, la deuxième fois pour quitter le script totalement.

# Proposition pour créer manuellement le nouveau fichier hosts.deny depuis un 
script lancé par sudo :

# Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) : 
https://hosts.ubuntu101.co.za/superhosts.deny
sudo cp /etc/hosts.deny /etc/hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant que simple 
utilisateur.
# Arrêter le script si le fichier ne peut pas être téléchargé.
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
sudo -s
cat /tmp/superhosts.deny > /etc/hosts.deny
exit
rm /tmp/superhosts.deny


# Proposition pour créer le nouveau fichier hosts.deny depuis une tâche cron 
lancée avec la crontab de root :

# Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) : 
https://hosts.ubuntu101.co.za/superhosts.deny
cp /etc/hosts.deny /etc/hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant que simple 
utilisateur.
# Arrêter le script si le fichier ne peut pas être téléchargé.
sudo - utilisateur_normal
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
# On quitte le simple utilisateur pour copier le contenu du fichier temporaire 
vers le fichier appartenant à root:root
exit
cat /tmp/superhosts.deny > /etc/hosts.deny
# On supprime le fichier temporaire avec le simple utilisateur :
sudo - utilisateur_normal
rm /tmp/superhosts.deny
# On quitte, deux fois (?)
exit
exit

Re: Should I enable "testing"

[Sven Hartge]

J.Arun Mani  wrote:

> The question is, shall I revert back to "stable"?

At this point, the only sure way to downgrade to stable is via a
reinstall, because downgrading a package is not supported (in general).

Why is this?

While many programs don't store anything on disk that is version
dependent, this does not hold true for every one.

Image a tool "foobar-1.1.0", which stores some data in a file. Now a new
version is installed, "foobar-2.0.4" and during upgrade or the first
time it is run, it converts the data in the file into a new format that
the old version 1.1.0 cannot understand.

If you now dowgrade the package, you will get errors or worse, lose or
corrupt your data.

Similarly with some packages moving directories and files around during
the upgrade process. Downgrading them will not revert that move and the
older package will either operate as if no data exists or throw errors.

And even *if* after the downgrade of the installed packages the system
seems to work normally, you never know if there wasn't some subtle error
introduced which will catch up to you later.

During my now over 20 years of using and administering Debian and
Debian-derived systems unclean downgrades sometime during the lifetime
of a system was among the most reasons for future failures during
operation or upgrades.

TL,DR: So my advise is: Keep it as it is, just change "testing" to "bullseye"
so you will stay on the new stable release once it is released.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Should I enable "testing"

[Brian]

On Sat 09 May 2020 at 12:12:08 +0200, Jean-Philippe MENGUAL wrote:
 
> Le 09/05/2020 à 09:44, J.Arun Mani a écrit :

[Good advice snipped]

> > deb http://deb.debian.org/debian  testing main
> > deb-src http://deb.debian.org/debian 
> > testing main
> > ```
> > Then I got some 1 GB of updates and I installed those. So far so good,
> > but now I'm having a rest-less heart that I did something wrong. I feel
> > like I should have stayed in "stable". This now troubles me.
> 
> Too late := Indeed you now are under testing intead of stable. You will have
> more recent packages and more frequent updates. In general testing works all
> right, but you are not as protected against potential bugs as stable,
> because testing is a repo for testing. And fixes come about 10 days later,
> the time to be accepted and tested in unstable

  deb http://deb.debian.org/debian testing main

I would consider changing "testing" to "bullseye". That way, when
testing eventually becomes the new stable, you will no longer be using
the testing distribution.

  deb-src http://deb.debian.org/debian testing main

Unless you are building (compiling) packages, you could delete this
line.

> > The question is, shall I revert back to "stable"?
> 
> No, would be impossible and catastrophic. Either re-install, or try testing
> now, could be good for you. Reverting a such big upgrade is impossible (or
> very difficult and unsafe)

Staying on bullseye is not likely to be such a disastrous move.

-- 
Brian.

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[Sébastien NOBILI]

Bonjour,

Le 2020-05-09 12:46, G2PC a écrit :

 # Utiliser le lien direct vers le fichier superhosts.deny (Plus de
15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny
 cd /etc
 sudo cp hosts.deny hosts.deny.bak


J'éviterais ce type de construction (changement de dossier puis copie 
avec des
noms relatifs). Il risque d'arriver un jour où tu 
ajouteras/modifieras/supprimeras
une ligne qui fera que la copie relative ne se fera plus depuis le bon 
endroit.


Je privilégierais ça :

sudo cp /etc/hosts.deny /etc/hosts.deny.bak


 # On peut télécharger le fichier dans le répertoire /tmp en tant
que simple utilisateur :
 wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp


Tu devrais interrompre ici si wget n'aboutit pas :

wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1


 cat /tmp/superhosts.deny >> /etc/hosts.deny


Chevron simple (">") plutôt non ? tu veux remplacer le contenu plutôt 
que

l'ajouter à la suite (si j'ai bien suivi)…

Sébastien

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[G2PC]

> echo "X"
> echo "Y"
> echo "Z"
>
> en :
>
> cat <<'EOF'
> X
> Y
> Z
> EOF
J'ai pris note.

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[G2PC]

> En fait, si d'aventure il y avait une tentative d'exploiter une
> vulnérabilité dans wget(1), alors cela n'affecterait que le
> compte qui aura lancé la commande.
Pasque wget a des vulnérabilités aussi. Nom d'un gruyère !
>> De plus si on utilise ce script via crontab de root, le sudo ne sera pas
>> utilisé, et, éventuellement, on récupèrera le fichier directement via le
>> script lancé depuis la crontab de root, donc, en root.
> Il est possible de céder ses drois de super utilisateur, avec
> su(8) ou sudo(8) depuis un crontab(1) appartenant à root, en se
> rabaissant aux droits d'un utilisateur normal, par exemple au
> hasard nobody:
Je ne sais pas ou tu a copier l'explication mais droits prend un " t " ;)
>
>   su - nobody -c 'wget https://example.org/index.html -P /tmp'
>   sudo -u nobody wget https://example.org/index.html -P /tmp
>
> Un détail auquel je n'ai pas pensé précédemment, la commande
> mv(1) conserve les utilisateurs et groupes, donc il faudra
> penser attribuer le fichier à root et au groupe root avec
> chown(1) avant de déplacer le fichier ou bien lancer à nouveau
> une commande cp(1).
" il faudra penser A attribuer " -> Les traductions ont des failles ;)

Vu,
Je suis passé de 4 à 7/10 lignes.
Si ça me semble correcte pour un lancement à la main, je ne sais plus
trop ou j'en suis pour un lancement du même script depuis la crontab de
root.
Mon script tel que proposé ici utilise sudo cp et par la suite sudo -s

Lors d'une tache administrative lancée depuis la crontab de root, puis
je laisser le script ainsi, ou, faudrait t'il faire disparaître les sudo
et les sudo -s
Je pense que cela fonctionnerait avec les sudo comme ci-dessous, mais,
par contre, est ce qu'ils ont encore du sens dans un script lancé par root .
Noter que j'ai bien lu ton explication, su ou sudo pourraient /
devraient être utilisés pour changer d'utilisateur avec su - ou sudo -
utilisateur.


 # Proposition pour une copie manuelle
 # Utiliser le lien direct vers le fichier superhosts.deny (Plus de
15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny
 cd /etc
 *sudo cp* hosts.deny hosts.deny.bak
 # On peut télécharger le fichier dans le répertoire /tmp en tant que
simple utilisateur :
 wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp
* sudo -s*
 cat /tmp/superhosts.deny >> /etc/hosts.deny
 *exit*
 rm /tmp/superhosts.deny


# Proposition pour un script lancé depuis une tâche cron avec la crontab
de root
# Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo)
: https://hosts.ubuntu101.co.za/superhosts.deny
 cd /etc
cp hosts.deny hosts.deny.bak
 # On peut télécharger le fichier dans le répertoire /tmp en tant que
simple utilisateur :
* sudo - utilisateur_normal*
 wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp
# On quitte le simple utilisateur pour copier le contenu du fichier
temporaire vers le fichier appartenant à root:root
 *exit*
 cat /tmp/superhosts.deny >> /etc/hosts.deny
 # On supprime le fichier temporaire avec le simple utilisateur :
 sudo utilisateur_normal
 rm /tmp/superhosts.deny
 # On quitte, deux fois (?) Une fois pour revenir à root, une seconde
pour quitter la fin du script (?)
 exit
 exit

> Comme quoi, en quatre ligne, il y a tout de même des choses à
> dire...  :)
Effectivement.
>>> Tout cela suppose que vous faites confiance au service délivré
>>> par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans
>>> votre /etc/hosts.deny, cat ils seraient en position de rendre
>>> votre machine inaccessible en mettant l'Internet complet dans ce
>>> fichier.
>> C'est certain et effectivement, il me faut ici faire confiance au
>> contenu, ce qui peut être affiné, je suppose avec des contrôles de
>> certificats, ou, une politique de controle de /md5sum, ou les deux, et,
>> peut être encore d'autres choses./
> md5sum(1) permet de vérifier l'intégrité du fichier, pour
> s'assurer qu'il n'y a pas eu de morceaux perdus ou corrompus
> pendant le transfert.  Mais oui, il y a d'autres possibilités:
> j'utilise gpg(1) pour vérifier à la fois l'intégrité et
> l'autenticité de certains fichiers, pour m'assurer qu'ils ont
> bien été construits par la personne qui a signé l'archive ;
> sachant que même avec cette technique, il peut y avoir des
> ratés.  Lisez plutôt la page suivante pour un cas rencontré dans
> la vie réelle :
>
>   https://www.kernel.org/category/signatures.html
>
> Le gestionnaire de paquets APT utilise d'ailleurs cette méthode
> pour s'assurer que le dépôt ou les paquets ont bien été
> construits par les développeurs Debian, et pas quelqu'un autre ;
> d'où les questions de configuration de GPG apparaissant dans le
> fil de discussion « reprepro » lancé par Marc Chantreux.  Malgré
> la mise en place de cette technique, ça n'a pas empêché un
> incident fâcheux avec apt l'an dernier :
>
>   https://www.debian.org/security/2019/dsa-4371
Effectivement j'ai déjà pu constater ça, avec le paquet secure ou
équivalent, qui demande à être installé, pour 

Re: Should I enable "testing"

[Jean-Philippe MENGUAL]

Le 09/05/2020 à 09:44, J.Arun Mani a écrit :

Hi
Out of some curiosity, I enabled "testing" repo last night. So I my 
/etc/apt/sources.list looks like this:

```
# See https://wiki.debian.org/SourcesList 
 for more information.

deb http://deb.debian.org/debian  buster main
deb-src http://deb.debian.org/debian  
buster main


2 previous lines to be removed, now useless

deb http://deb.debian.org/debian  
buster-updates main
deb-src http://deb.debian.org/debian  
buster-updates main


idem

deb http://security.debian.org/debian-security/ 
 buster/updates main
deb-src http://security.debian.org/debian-security/ 
 buster/updates main


idem


deb http://deb.debian.org/debian  testing main
deb-src http://deb.debian.org/debian  
testing main

```
Then I got some 1 GB of updates and I installed those. So far so good, 
but now I'm having a rest-less heart that I did something wrong. I feel 
like I should have stayed in "stable". This now troubles me.


Too late := Indeed you now are under testing intead of stable. You will 
have more recent packages and more frequent updates. In general testing 
works all right, but you are not as protected against potential bugs as 
stable, because testing is a repo for testing. And fixes come about 10 
days later, the time to be accepted and tested in unstable



The question is, shall I revert back to "stable"?


No, would be impossible and catastrophic. Either re-install, or try 
testing now, could be good for you. Reverting a such big upgrade is 
impossible (or very difficult and unsafe)



If yes, how can I do it? Possibly uninstall those new packages and 
downgrade to stable ones.


Re-install

Regards



Please help me out
J Arun Mani

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[l0f4r0]

8 mai 2020 à 18:20 de g...@visionduweb.com:

>   > 
> https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C3%A9#Mettre_.C3.A0_jour_le_fichier_.2Fetc.2Fhosts_automatiquement_tous_les_mois
>
...et j'oubliais, également remplacer les :

echo "X"
echo "Y"
echo "Z"

en :

cat <<'EOF'
X
Y
Z
EOF

Bien cordialement,
l0f4r0

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[l0f4r0]

Bonjour,

8 mai 2020 à 18:20 de g...@visionduweb.com:

> https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C3%A9#Mettre_.C3.A0_jour_le_fichier_.2Fetc.2Fhosts_automatiquement_tous_les_mois
>
1) Tu gagnerais en flexibilité/rapidité/lisibilité à modifier tes :

cmd1 >>/etc/hosts
cmd2 >>/etc/hosts
cmdX >>/etc/hosts

en :

{
cmd1
cmd2
cmdX
} >>/etc/hosts

2) C'est pas optimal en effet de se baser sur les numéros de lignes pour ton 
sed...
Peut-être le plus simple serait de ne pas ajouter à la base ces lignes doublons 
depuis le fichier téléchargé avec un truc du genre :

grep -vf /etc/hosts /tmp/hosts >>/etc/hosts

NB : la commande marche mais je t'invite à vérifier qu'il n'y a pas d'effet de 
bord en pratique. Il est possible qu'il faille être un peu plus fin...

Bien cordialement,
l0f4r0

Re: ...

[Alexander V. Makartsev]

On 08.05.2020 23:14, Thomas McAtee Jr wrote:
> For some reason unable to file a bug report. Tried under kernel and the
> Linux Image as well.
>
> Here is my issue. I'm using Debian Testing Mate and a couple days ago I
> did my update/upgrades. I received the new Linux Image 5.6.0.1. After I
> did the update/upgrade I also did the dist-upgrade as well like I
> usually do.
>
> 01:00.0 VGA compatible controller: NVIDIA Corporation G72 [GeForce 7300
> LE] (rev a1)
>
My guess you've got a "nouveau" driver regression, or support for your
pretty old hardware was dropped from this driver\kernel.
You could try proprietary driver, but since you've trying Bullseye
you're out of options, because last version of Nvidia proprietary
drivers that supported your VGA is 304.xx
and "nvidia-legacy-304xx-driver" package is available for Stretch, but
not for current Stable or Testing.

Still, you can try to install 304.137 driver package from official
Nvidia website [1], but this is not Debian-supported way of getting
drivers and by doing this you can break your system.


[1] https://www.nvidia.com/download/driverResults.aspx/123709/en-us

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄ 

Re: Should I enable "testing"

[Andrei POPESCU]

On Sb, 09 mai 20, 07:44:43, J.Arun Mani wrote:
> ```
> Then I got some 1 GB of updates and I installed those. So far so good, 
> but now I'm having a rest-less heart that I did something wrong. I 
> feel like I should have stayed in "stable". This now troubles me.
> The question is, shall I revert back to "stable"?

If you need to ask then probably yes.

> If yes, how can I do it? Possibly uninstall those new packages and downgrade 
> to stable ones.

Downgrading of packages is not supported, even if it does work in many 
cases.

Safer options would be:

1. Find all packages that are newer and remove them, then install the 
stable version.

2. Reinstall

Or you could just stay with testing ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Should I enable "testing"

[J.Arun Mani]

Hi
Out of some curiosity, I enabled "testing" repo last night. So I my 
/etc/apt/sources.list looks like this:
```
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian buster main
deb-src http://deb.debian.org/debian buster main

deb http://deb.debian.org/debian buster-updates main
deb-src http://deb.debian.org/debian buster-updates main

deb http://security.debian.org/debian-security/ buster/updates main
deb-src http://security.debian.org/debian-security/ buster/updates main

deb http://deb.debian.org/debian testing main
deb-src http://deb.debian.org/debian testing main
```
Then I got some 1 GB of updates and I installed those. So far so good, but now 
I'm having a rest-less heart that I did something wrong. I feel like I should 
have stayed in "stable". This now troubles me.
The question is, shall I revert back to "stable"?
If yes, how can I do it? Possibly uninstall those new packages and downgrade to 
stable ones.

Please help me out
J Arun Mani

Re: systemd

[Fabien R]

On 08/05/2020 16:58, Bernard Schoenacker wrote:
> bonjour,
> 
> il est possible de quitter systemd sans changer de distribution
> et tu passes par un équivalent unix : rc.d
Ce n'est pas vraiment un changement de distribution car devuan = debian sans 
systemd.

--
Fabien

Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?

[Étienne Mollier]

Bonjour,

G2PC, on 2020-05-08 18:06:36 +0200:
> J'entends la proposition d'utiliser un utilisateur normal pour récupérer
> le fichier.
> mais ensuite, on utilise sudo ( manuellement ) pour déplacer le fichier
> du /tmp vers /etc

En fait, si d'aventure il y avait une tentative d'exploiter une
vulnérabilité dans wget(1), alors cela n'affecterait que le
compte qui aura lancé la commande.  Évidemment, si le contenu du
fichier téléchargé peut être affecté par la vulnérabilité en
question, alors il y aurait fort à parier que la commande finale
qui écrase le fichier système puisse poser problème.

> De plus si on utilise ce script via crontab de root, le sudo ne sera pas
> utilisé, et, éventuellement, on récupèrera le fichier directement via le
> script lancé depuis la crontab de root, donc, en root.

Il est possible de céder ses drois de super utilisateur, avec
su(8) ou sudo(8) depuis un crontab(1) appartenant à root, en se
rabaissant aux droits d'un utilisateur normal, par exemple au
hasard nobody:

su - nobody -c 'wget https://example.org/index.html -P /tmp'
sudo -u nobody wget https://example.org/index.html -P /tmp

Un détail auquel je n'ai pas pensé précédemment, la commande
mv(1) conserve les utilisateurs et groupes, donc il faudra
penser attribuer le fichier à root et au groupe root avec
chown(1) avant de déplacer le fichier ou bien lancer à nouveau
une commande cp(1).

Comme quoi, en quatre ligne, il y a tout de même des choses à
dire...  :)

> > Tout cela suppose que vous faites confiance au service délivré
> > par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans
> > votre /etc/hosts.deny, cat ils seraient en position de rendre
> > votre machine inaccessible en mettant l'Internet complet dans ce
> > fichier.
> 
> C'est certain et effectivement, il me faut ici faire confiance au
> contenu, ce qui peut être affiné, je suppose avec des contrôles de
> certificats, ou, une politique de controle de /md5sum, ou les deux, et,
> peut être encore d'autres choses./

md5sum(1) permet de vérifier l'intégrité du fichier, pour
s'assurer qu'il n'y a pas eu de morceaux perdus ou corrompus
pendant le transfert.  Mais oui, il y a d'autres possibilités:
j'utilise gpg(1) pour vérifier à la fois l'intégrité et
l'autenticité de certains fichiers, pour m'assurer qu'ils ont
bien été construits par la personne qui a signé l'archive ;
sachant que même avec cette technique, il peut y avoir des
ratés.  Lisez plutôt la page suivante pour un cas rencontré dans
la vie réelle :

https://www.kernel.org/category/signatures.html

Le gestionnaire de paquets APT utilise d'ailleurs cette méthode
pour s'assurer que le dépôt ou les paquets ont bien été
construits par les développeurs Debian, et pas quelqu'un autre ;
d'où les questions de configuration de GPG apparaissant dans le
fil de discussion « reprepro » lancé par Marc Chantreux.  Malgré
la mise en place de cette technique, ça n'a pas empêché un
incident fâcheux avec apt l'an dernier :

https://www.debian.org/security/2019/dsa-4371

Amicalement,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/


signature.asc
Description: PGP signature

Re: ajuda amb problema amb audio (pulseaudio?)

[Àlex]

Benvolguts/des,

Sabeu si hi ha alguna mena d'arxiu històric de nuclis de Linux?

Per exemple, aquests últims dies Debian Testing ha actualitzat a nucli
5.6, però existeix algún lloc on encara es pugui descarregar el packet
d'un nucli anterior: 5.5 , 5.2 , etc ? o toca descarregar les fonts a
kernel.org i compilar el nucli que vull recuperar?

Aprofito per explicar-vos com continua la meva aventura amb l'audio:

Continuava fent "pulseaudio -k" perquè en iniciar el sistema la meva
tarja de so de vegades apareixia com inhabilitada, especialment si a la
sessió anterior havia fet servir un micrófon. Després d'aquesta comanda
tot funcionava bé.

Però després d'actualitzar al nucli 5.6 he perdut tot el so per HDMI. Ja
he reportat el bug als mantenidors del paquet. Per sort encara tinc el
nucli 5.5 i un nucli 4.19 que he agafat de la Debian estable, i si
arrenco amb aquests altres nuclis funciona el so.

$ lspci VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT
710] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP
Audio Controller (rev a1)

Al perfil de l'àudio quan arrenco amb nucli que no sigui 5.6, apareix el
canal HDMI bo "Digital Stereo (HDMI 2) Output", i aquest é l'únic perfil
de les propietats d'audio.

Però quan arrenco amb nucli 5.6 els perfils que apareixen a les
propietats d'audio són els "oposats" (els canals "desconnectats"):
"Digital Stereo (HDMI) Output", "Digital Stereo (HDMI 3) Output",
"Digital Stereo (HDMI 4) Output", "Digital Stereo (HDMI 5) Output" .
Tots menys el canal anterior HDMI 2

Salutacions


El 16/4/20 a les 12:17, Àlex ha escrit:
> Estimada comunitat,
>
> Tinc un problema amb l'audio del meu equip, que fins ahir funcionava
> perfecte. Us vull explicar per si em podeu donar una pista, per què no
> sé per on tirar.
>
> Treballo amb una torre amb Debian Testing, connectada per HDMI a una
> antiga televisió que em fa de pantalla. Això vol dir que el dispositiu
> de sortida d'audio també és la targeta gràfica.
>
> Fins ahir tot anava bé. Ahir vaig de fer videoconferència i vaig haver
> de connectar un micro a la torre, i a les preferencies d'audio del meu
> escriptori Mate vaig escollir que el dispositiu d'entrada d'audio fos el
> connectar frontal de la torre. Tot va funcionar perfecte.
>
> Però avui en reiniciar l'equip no tinc so.
>
> Quan vaig a les preferències d'audio de Mate em diu que el dispositiu
> HDMI està inhabilitat.
>
> L'únic que fins ara em funciona és anar al terminal i escriure:
>
>
>    $ pulseaudio -k
>
>
> Després de fer això, si torno a les preferències d'audio de Mate ja puc
> fer servir el meu dispositiu HDMI, però en reiniciar l'equip torno a
> estar en les mateixes, sense audio.
>
> No tinc ni idea de quins són els fitxers de configuració que control.len
> això.
>
> Per cert, al teminal he intentat veure si es podia arreglar amb la
> comanda alsamixer, però no he pogut o no he sapigut
>
> Salut companys/es
>
>
>     Àlex