Re: Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?

2019-07-12 Thread Pascal Hambourg

Le 11/07/2019 à 14:38, Olivier a écrit :

Le jeu. 11 juil. 2019 à 14:04, Bernard Schoenacker <
bernard.schoenac...@free.fr> a écrit :


serait il possible de régler le mtu à 1492 sur la passerelle ?


Sauf erreur, le MTU était déjà réglé à 1492 sur le lien ppp0, si j'en crois
la sortie d' "ip link" .


Evidemment, sinon l'option --clamp-mss-to-pmtu serait sans effet.


ping -M do -s 1492 192.168.4.254
PING 192.168.4.254 (192.168.4.254) 1492(1520) bytes of data.
ping: local error: Message too long, mtu=1492

où 192.168.4.254 est l'IP de mon serveur PPPoE (sur lequel le MTU est aussi
valorisé à 1492).

La valeur la plus grande pour laquelle le ping ci-dessus réussit est 1464


1464 + 8 (en-tête ICMP) + 20 (en-tête IPv4) = 1492


(le hack iptables ne change rien à cet égard).


Normal, il n'affecte que les paquets TCP.
Effectivement, le mot est juste : c'est un hack.



Re: Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?

2019-07-12 Thread Pascal Hambourg

Le 11/07/2019 à 12:53, Olivier a écrit :


Avec des captures Wireshark, j'ai vu que dans l'environnement en défaut, un
message "ICMP Don't Fragment" était émis.


Ça m'étonnerait. Ce type de message n'existe pas. Tu dois confondre avec 
"Fragmentation needed but DF (Don't Fragment) set".



Plus spécifiquement, j'aimerai a minima, savoir quelle commande permet de
détecter le problème corrigé par la cible -j TCPMSS --clamp-mss-to-pmtu de
mes règles iptables ?


Il n'existe pas de commande qui détecte le problème à coup sûr. Cette 
cible contourne un problème de gestion de MTU qui se situe dans le sens 
descendant : l'émetteur distant n'est pas informé que les paquets qu'il 
envoie sont trop gros (soit à cause d'un trou noir de MTU causé par un 
pontage PPPoe-PPP par exemple, soit à cause d'un routeur qui ne renvoie 
pas de message ICMP "Fragmentation needed" à l'émetteur, soit à cause 
d'un filtrage de ce message entre le routeur et l'émetteur, soit parce 
que l'émetteur ne tient pas compte de ce message).


Envoyer un gros ping avec -M do (fragmentation interdite) est vain : le 
ping sera bloqué dès l'émission alors que le problème à détecter se 
situe en réception. Envoyer un gros ping fragmenté a plus de chances de 
détecter quelque chose : la cible devrait envoyer une réponse fragmentée 
mais en cas de problème seul le petit fragment sera reçu par l'interface 
PPPoE.




Re: Don't disable recoomends by default

2019-07-12 Thread Andrei POPESCU
On Vi, 12 iul 19, 22:40:17, Brian wrote:
> On Sat 13 Jul 2019 at 00:17:49 +0300, Andrei POPESCU wrote:
> > 
> > This is not about "breaking" Debian, but confusing the user (why does mc 
> > open gziped files, but not zip?)
> 
> gzip is already on the system (Priority: required), unzip isn't. But a
> confused user wouldn't have this in mind. The recommendation is sound.

Nitpick: mc doesn't need to Depends: or Recommends: gzip because gzip is 
Essential: yes (see Policy 3.5).

For packages that are not Essential: yes an explicit Depends:, 
Recommends: or Suggests: would have to be added, regardless of the other 
package's priority.

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


signature.asc
Description: PGP signature


Re: useless localisation files

2019-07-12 Thread Andrei POPESCU
On Vi, 12 iul 19, 13:03:33, Pierre Frenkiel wrote:
> hi,
> when installing some packages (chromiun for example), I get a lot of
> useless languages (task-marathi-desktop task-nepali-desktop ...)

I would argue that no language is useless ;)

The localisation files, specific fonts and spelling dictionaries are 
indeed probably not needed by people not understanding the language.

Please try 'aptitude why task-marathi-desktop' to see why those packages 
are being installed.

> Is there a way to get rid of them?

Typically by uninstalling ;)

What did you try and didn't work?

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


signature.asc
Description: PGP signature


Re: Psychedelic GUI after stable update to buster

2019-07-12 Thread Charlie Kravetz
On Fri, 12 Jul 2019 20:22:55 -0400
ho...@rumormillnews.com wrote:

>> On Fri, 12 Jul 2019 17:52:43 -0400
>> ho...@rumormillnews.com wrote:
>>  
>>>Following recent 'buster' move to 'stable' I got wild psychedelic colors
>>>on my XFCE desktop, making it nearly impossible to read anything
>>>on-screen.
>>>
>>>Normally I'd have display set for 1024x768.  I've found I can get normal
>>>color on the GUI if I switch to 1600x900.  However, even then, if I
>>> switch
>>>to console (F1-F6) or if the screensaver comes on, on return the
>>>psychedelic colors are back.  If I log out / log in to the desktop,
>>> normal
>>>colors return with the 1600x900 setting only.
>>>
>>>AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
>>>firmware-linux-free and firmware-linux-nonfree are installed.
>>>
>>>Is this a bug?  Is there a fix? I'd like to get my normal colors and
>>>normal resolution back.  Thanks in advance for any help.
>>>  
>>
>>
>> Try a different theme. The switch from GTK-2 to GTK-3 results in a mess
>> if the wrong theme is used.
>>  
>
>Thanks. :)  Using GTK-ChTheme (which says it's for GTK+ 2, but I don't see
>a similar utility for GTK+ 3) I switched to Xfce 4.4 but got no
>improvement.  Should I be approaching this theme change some other way?
>

You have the right idea, however, perhaps try adwaita, which is a GTK-3
specific theme. 



Re: Don't disable recoomends by default

2019-07-12 Thread Jonas Smedegaard
Quoting John Crawley (2019-07-12 22:52:55)
> On 2019-07-13 06:39, Jonas Smedegaard wrote:
> > ...some developers wrongly thought that recommends was same as 
> > suggests and therefore used depends far more than really needed.
> 
> This. Installing with Recommends used to pull in a whole slew of 
> things that should have been Suggests, so users got into the habit of 
> installing without.
> 
>  > The bug got fixed, and slowly developers learned to make proper use 
>  > of recommends as it was always intended.
> 
> Most developers anyway.
> 
> I remember when Debian systems started installing Recommends /by 
> default/ - and there was an outcry - but was this a fixed bug in 
> apt-get itself? Wasn't Debian Policy also amended a bit at that point 
> to make the purpose of Recommends clearer? Or had it always been that 
> way...

Yes, it was a bugfix: Before the change apt-get was _broken_ and after 
the change apt-get behaved as intended.

Yes, there has over the years been various edits to Policy which only 
clarified existing meaning, without changing any meaning - including 
clarifications to what "Recommends" means.

Yes, some interpreted things differently and wanted back the "good old 
days" - despite being unintended and undocumented and suboptimal.

Yes, some developers took quite some time to adapt to the "new" reality 
of a properly working apt-get - and possibly some developers still are 
living in a bubble.  I hope not.


> Anyway, even if your system default is to install Recommends, apt-get 
> (and apt too?) always gets user approval before installing anything 
> beyond the package asked for. If the list looks too long (s)he can 
> always hit (N) and try again with 'apt-get install 
> --no-install-recommends '

...and suppressing recommends exeptionally like that is quite sensible.

Again, my strong criticism is only suppressing recommends by *default*.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Re: useless languages

2019-07-12 Thread David Christensen

On 7/12/19 4:03 AM, Pierre Frenkiel wrote:

hi,
when installing some packages (chromiun for example), I get a lot of
useless languages (task-marathi-desktop task-nepali-desktop ...)
Is there a way to get rid of them?

best regards,


I added the following line to my root .profile to prevent apt-get from 
downloading and installing 'recommended' packages;


alias apt-get='apt-get --no-install-recommends'


david



Re: Don't disable recoomends by default

2019-07-12 Thread John Crawley

On 2019-07-13 06:39, Jonas Smedegaard wrote:

...some developers wrongly thought that recommends was same as
suggests and therefore used depends far more than really needed.


This. Installing with Recommends used to pull in a whole slew of things 
that should have been Suggests, so users got into the habit of 
installing without.


> The bug got fixed, and slowly developers learned to make proper use of
> recommends as it was always intended.

Most developers anyway.

I remember when Debian systems started installing Recommends /by 
default/ - and there was an outcry - but was this a fixed bug in apt-get 
itself? Wasn't Debian Policy also amended a bit at that point to make 
the purpose of Recommends clearer? Or had it always been that way...


Anyway, even if your system default is to install Recommends, apt-get 
(and apt too?) always gets user approval before installing anything 
beyond the package asked for. If the list looks too long (s)he can 
always hit (N) and try again with

'apt-get install --no-install-recommends '

--
John



Re: Wpa_supplicant Error: No such device

2019-07-12 Thread Patrick Bartek
On Fri, 12 Jul 2019 16:07:23 -0500
David Wright  wrote:

> On Fri 12 Jul 2019 at 12:36:33 (-0700), Patrick Bartek wrote:
> > On Fri, 12 Jul 2019 06:22:16 - (UTC)
> > Bert Riding  wrote:
> >   
> > > Yes, I'm sorry I didn't mention that my device name was merely an  
> > 
> > Didn't have to.  I understood.  It's just wlan0 USED to be the default
> > 1st wireless device, the last time I had to do this with another system
> > about 15 years ago, and I used it as a first test to bring UP the
> > device before reading the instructions. It failed, of course. Laziness.
> >   
> > > example.  I wonder if "ip link show" or "ls -l /sys/class/net" or the 
> > > obsolete "ifconfig a" give the same device name.  Udevadm might 
> > > help, too.  "udevadm info -e | grep .wl" for instance.  The name you are 
> > > using is the name using the MAC address, which is the last match as udev 
> > > lists the names, and won't be used if udev finds another name first.  See
> > > https://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/
> > >
> > 
> > Here's what that all shows on my system (wireless parts only).
> > Wireless USB dongle plugged in, but otherwise dormant.
> > 
> > ip a
> > 
> > 3: wlx00e04c2a23c4:  mtu 1500 qdisc noop state
> > DOWN mode DEFAULT group default qlen 1000 link/ether 00:e0:4c:2a:23:c4
> > brd ff:ff:ff:ff:ff:ff
> > 
> > ls -l /sys/class/net
> > 
> > lrwxrwxrwx 1 root root 0 Jul 12 07:48 wlx00e04c2a23c4  
> > -> 
> > ../../devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4  
> > 
> > /sbin/iw dev
> > 
> > phy#0
> > Interface wlx00e04c2a23c4
> > ifindex 3
> > wdev 0x1
> > addr 00:e0:4c:2a:23:c4
> > type managed
> > txpower 0.00 dBm
> > 
> > udevadm info -e | grep .wl
> > 
> > E: RFKILL_TYPE=wlan
> > P: /devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4
> > E:
> > DEVPATH=/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4
> > E: DEVTYPE=wlan E: ID_NET_NAME=wlp0s18f2u3
> > E: ID_NET_NAME_MAC=wlx00e04c2a23c4
> > E: ID_NET_NAME_PATH=wlp0s18f2u3
> > E: INTERFACE=wlx00e04c2a23c4
> > E:
> > SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlx00e04c2a23c4 
> > /sys/subsystem/net/devices/wlx00e04c2a23c4
> > 
> > As you can see, the wlx name is the only one that shows as far as I
> > can find. ifconfig is not installed.  
> 
> Here's mine. As you can see, it lists the iwlwifi driver,
> but I don't see anything for yours.
> 
> E: DRIVER=iwlwifi
> E: RFKILL_TYPE=wlan
> P: /devices/pci:00/:00:1c.2/:02:00.0/net/wlp2s0
> E: DEVPATH=/devices/pci:00/:00:1c.2/:02:00.0/net/wlp2s0
> E: DEVTYPE=wlan
> E: ID_NET_DRIVER=iwlwifi
> E: ID_NET_NAME=wlp2s0
> E: ID_NET_NAME_MAC=wlx0c8bfd0b67fb
> E: ID_NET_NAME_PATH=wlp2s0
> E: INTERFACE=wlp2s0
> E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlp2s0 
> /sys/subsystem/net/devices/wlp2s0
> E: RFKILL_NAME=ideapad_wlan
> E: RFKILL_TYPE=wlan

Thanks.  Looks like your wifi is pci.  Right?  Mine's a USB and
DOWN/inactive (I was on wired ethernet) when I did the udevadm.  But
the next time I bring it UP, I'll see what udevadm reports as the
driver. Probably nl80211.

Thanks, again, for the info.  Every little bit helps to track down the
problem.

B



Re: Psychedelic GUI after stable update to buster

2019-07-12 Thread hobie
> On Fri, 12 Jul 2019 17:52:43 -0400
> ho...@rumormillnews.com wrote:
>
>>Following recent 'buster' move to 'stable' I got wild psychedelic colors
>>on my XFCE desktop, making it nearly impossible to read anything
>>on-screen.
>>
>>Normally I'd have display set for 1024x768.  I've found I can get normal
>>color on the GUI if I switch to 1600x900.  However, even then, if I
>> switch
>>to console (F1-F6) or if the screensaver comes on, on return the
>>psychedelic colors are back.  If I log out / log in to the desktop,
>> normal
>>colors return with the 1600x900 setting only.
>>
>>AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
>>firmware-linux-free and firmware-linux-nonfree are installed.
>>
>>Is this a bug?  Is there a fix? I'd like to get my normal colors and
>>normal resolution back.  Thanks in advance for any help.
>>
>
>
> Try a different theme. The switch from GTK-2 to GTK-3 results in a mess
> if the wrong theme is used.
>

Thanks. :)  Using GTK-ChTheme (which says it's for GTK+ 2, but I don't see
a similar utility for GTK+ 3) I switched to Xfce 4.4 but got no
improvement.  Should I be approaching this theme change some other way?



Re: Mise à jour jessie --> buster

2019-07-12 Thread hamster
Le 13/07/2019 à 01:34, Gaëtan Perrier a écrit :
> Le home n'est pas suffisant. Il y a pas mal de chose dans /var /etc
> /opt /usr/local ...

Sur un serveur oui, sur un poste de travail pas tant que ca et c'est
très facile de reprendre les fichiers dans la sauvegarde de l'ancienne
version et les remettre.



Re: systemd-container login as root no longer possible?

2019-07-12 Thread Michael Biebl
Hi

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830255
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731656

might be related.
Does it help if you add pts/0 to /etc/securetty inside your buster
container?
Would be great if you can report back if that fixes your issue.
If you want to use machinectl, you also need to have dbus installed
inside your container.

Interesting to see that /etc/securetty has apparently been removed just
recently. That change is unstable only, i.e. won't help you for a buster
container. See
https://tracker.debian.org/news/1042624/accepted-shadow-147-1-source-into-unstable/


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Psychedelic GUI after stable update to buster

2019-07-12 Thread Charlie Kravetz
On Fri, 12 Jul 2019 17:52:43 -0400
ho...@rumormillnews.com wrote:

>Following recent 'buster' move to 'stable' I got wild psychedelic colors
>on my XFCE desktop, making it nearly impossible to read anything
>on-screen.
>
>Normally I'd have display set for 1024x768.  I've found I can get normal
>color on the GUI if I switch to 1600x900.  However, even then, if I switch
>to console (F1-F6) or if the screensaver comes on, on return the
>psychedelic colors are back.  If I log out / log in to the desktop, normal
>colors return with the 1600x900 setting only.
>
>AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
>firmware-linux-free and firmware-linux-nonfree are installed.
>
>Is this a bug?  Is there a fix? I'd like to get my normal colors and
>normal resolution back.  Thanks in advance for any help.
>


Try a different theme. The switch from GTK-2 to GTK-3 results in a mess
if the wrong theme is used. 



Re: Mise à jour jessie --> buster

2019-07-12 Thread Gaëtan Perrier
Le home n'est pas suffisant. Il y a pas mal de chose dans /var /etc /opt 
/usr/local ...

Le 12 juillet 2019 22:15:22 GMT+02:00, hamster  a écrit :
>Le 12/07/2019 à 21:07, ajh-valmer a écrit :
>> Install en partant de zero, il faut recréer ensuite tout son
>> environnement,
>> ça risque de prendre plus de temps qu'un upgrade voire 2.
>
>Comme déjà dit, avec une partoche /home séparée a laquelle on ne touche
>pas, on retrouve son environnement tel qu'il était sans rien avoir a
>faire. Il n'y a que la partie configuration système qui est a refaire,
>et c'est pas grand chose : il suffit de copier les fichiers de
>configuration de la version précédente. Et bien sur reinstaller les
>logiciels qu'on avait, ce qui se fait en une seule commande si on en
>avait sauvegardé la liste avant.

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Psychedelic GUI after stable update to buster

2019-07-12 Thread hobie
Following recent 'buster' move to 'stable' I got wild psychedelic colors
on my XFCE desktop, making it nearly impossible to read anything
on-screen.

Normally I'd have display set for 1024x768.  I've found I can get normal
color on the GUI if I switch to 1600x900.  However, even then, if I switch
to console (F1-F6) or if the screensaver comes on, on return the
psychedelic colors are back.  If I log out / log in to the desktop, normal
colors return with the 1600x900 setting only.

AMD A10-7860K Radeon R7.  ASUSTEK A68HM-K motherboard.
firmware-linux-free and firmware-linux-nonfree are installed.

Is this a bug?  Is there a fix? I'd like to get my normal colors and
normal resolution back.  Thanks in advance for any help.



iOS AirPlay and CUPS

2019-07-12 Thread James Medeiros
Hi all -

Maybe this is too vague, but wonder if anyone is aware of general problems
with AirPlay and CUPS.

I set up an orange Pi today as a print server. Installed cups, cups-daemon,
avahi, etc. and the Samsung printer drivers (it’s an SCX-3200)

I can print successfully from my other GNU/Linux boxes... our iOS devices
see the printer, but nothing happens when jobs are sent - they don’t show
up in the queue.

Thanks for any guidance,
James


Re: Don't disable recoomends by default

2019-07-12 Thread Brian
On Sat 13 Jul 2019 at 00:17:49 +0300, Andrei POPESCU wrote:

> On Vi, 12 iul 19, 20:21:08, Reco wrote:
> > 
> > I say - if the user wants to "break" a system by not installing the
> > Recommends - let them. Whenever it's curiosity, a way of learning
> > something new or just a wish to do an OS liposuction.
> 
> Sure.
> 
> Still, I would avoid recommending (ha!) turning off Recommends except if 
> a poster has a specific problem that might be solved by it (e.g. space 
> constraints).
> 
> > Either way it won't break (a hint - Recommends weren't always the
> > default), or the user will learn something new in a process.
> 
> I'm pretty sure Jonas was around when that happened ;)
> 
> > Besides, they don't call Debian the Universal OS for nothing. It can
> > tolerate the surprising amount of "breakage".
> 
> This is not about "breaking" Debian, but confusing the user (why does mc 
> open gziped files, but not zip?)

gzip is already on the system (Priority: required), unzip isn't. But a
confused user wouldn't have this in mind. The recommendation is sound.

-- 
Brian.



Re: Don't disable recoomends by default

2019-07-12 Thread Jonas Smedegaard
Quoting Andrei POPESCU (2019-07-12 18:17:49)
> On Vi, 12 iul 19, 20:21:08, Reco wrote:
> > I say - if the user wants to "break" a system by not installing the 
> > Recommends - let them. Whenever it's curiosity, a way of learning 
> > something new or just a wish to do an OS liposuction.
> 
> Sure.
> 
> Still, I would avoid recommending (ha!) turning off Recommends except 
> if a poster has a specific problem that might be solved by it (e.g. 
> space constraints).
> 
> > Either way it won't break (a hint - Recommends weren't always the 
> > default), or the user will learn something new in a process.
> 
> I'm pretty sure Jonas was around when that happened ;)

Right: When APT was introduced, the command-line tool apt-get was 
initially intended only as a demo of what the engine could do and lacked 
some features - most notably it had a bug so that it wrongly treated all 
recommends same as suggests.

Personally I didn't notice that because I switched to using the far more 
powerful APT frontend aptitude when that emerged, but apt-get was 
popular and some developers wrongly thought that recommends was same as 
suggests and therefore used depends far more than really needed.

The bug got fixed, and slowly developers learned to make proper use of 
recommends as it was always intended.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Re: Don't disable recoomends by default

2019-07-12 Thread Andrei POPESCU
On Vi, 12 iul 19, 20:21:08, Reco wrote:
> 
> I say - if the user wants to "break" a system by not installing the
> Recommends - let them. Whenever it's curiosity, a way of learning
> something new or just a wish to do an OS liposuction.

Sure.

Still, I would avoid recommending (ha!) turning off Recommends except if 
a poster has a specific problem that might be solved by it (e.g. space 
constraints).

> Either way it won't break (a hint - Recommends weren't always the
> default), or the user will learn something new in a process.

I'm pretty sure Jonas was around when that happened ;)

> Besides, they don't call Debian the Universal OS for nothing. It can
> tolerate the surprising amount of "breakage".

This is not about "breaking" Debian, but confusing the user (why does mc 
open gziped files, but not zip?)

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


signature.asc
Description: PGP signature


Re: Wpa_supplicant Error: No such device

2019-07-12 Thread David Wright
On Fri 12 Jul 2019 at 12:36:33 (-0700), Patrick Bartek wrote:
> On Fri, 12 Jul 2019 06:22:16 - (UTC)
> Bert Riding  wrote:
> 
> > Yes, I'm sorry I didn't mention that my device name was merely an
> 
> Didn't have to.  I understood.  It's just wlan0 USED to be the default
> 1st wireless device, the last time I had to do this with another system
> about 15 years ago, and I used it as a first test to bring UP the
> device before reading the instructions. It failed, of course. Laziness.
> 
> > example.  I wonder if "ip link show" or "ls -l /sys/class/net" or the 
> > obsolete "ifconfig a" give the same device name.  Udevadm might 
> > help, too.  "udevadm info -e | grep .wl" for instance.  The name you are 
> > using is the name using the MAC address, which is the last match as udev 
> > lists the names, and won't be used if udev finds another name first.  See
> > https://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/
> >  
> 
> Here's what that all shows on my system (wireless parts only).
> Wireless USB dongle plugged in, but otherwise dormant.
> 
> ip a
> 
> 3: wlx00e04c2a23c4:  mtu 1500 qdisc noop state
> DOWN mode DEFAULT group default qlen 1000 link/ether 00:e0:4c:2a:23:c4
> brd ff:ff:ff:ff:ff:ff
> 
> ls -l /sys/class/net
> 
> lrwxrwxrwx 1 root root 0 Jul 12 07:48 wlx00e04c2a23c4
> -> ../../devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4
> 
> /sbin/iw dev
> 
> phy#0
>   Interface wlx00e04c2a23c4
>   ifindex 3
>   wdev 0x1
>   addr 00:e0:4c:2a:23:c4
>   type managed
>   txpower 0.00 dBm
> 
> udevadm info -e | grep .wl
> 
> E: RFKILL_TYPE=wlan
> P: /devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4
> E:
> DEVPATH=/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4
> E: DEVTYPE=wlan E: ID_NET_NAME=wlp0s18f2u3
> E: ID_NET_NAME_MAC=wlx00e04c2a23c4
> E: ID_NET_NAME_PATH=wlp0s18f2u3
> E: INTERFACE=wlx00e04c2a23c4
> E:
> SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlx00e04c2a23c4 
> /sys/subsystem/net/devices/wlx00e04c2a23c4
> 
> As you can see, the wlx name is the only one that shows as far as I
> can find. ifconfig is not installed.

Here's mine. As you can see, it lists the iwlwifi driver,
but I don't see anything for yours.

E: DRIVER=iwlwifi
E: RFKILL_TYPE=wlan
P: /devices/pci:00/:00:1c.2/:02:00.0/net/wlp2s0
E: DEVPATH=/devices/pci:00/:00:1c.2/:02:00.0/net/wlp2s0
E: DEVTYPE=wlan
E: ID_NET_DRIVER=iwlwifi
E: ID_NET_NAME=wlp2s0
E: ID_NET_NAME_MAC=wlx0c8bfd0b67fb
E: ID_NET_NAME_PATH=wlp2s0
E: INTERFACE=wlp2s0
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlp2s0 
/sys/subsystem/net/devices/wlp2s0
E: RFKILL_NAME=ideapad_wlan
E: RFKILL_TYPE=wlan

Cheers,
David.



Re: Mise à jour jessie --> buster

2019-07-12 Thread hamster
Le 12/07/2019 à 21:07, ajh-valmer a écrit :
> Install en partant de zero, il faut recréer ensuite tout son
> environnement,
> ça risque de prendre plus de temps qu'un upgrade voire 2.

Comme déjà dit, avec une partoche /home séparée a laquelle on ne touche
pas, on retrouve son environnement tel qu'il était sans rien avoir a
faire. Il n'y a que la partie configuration système qui est a refaire,
et c'est pas grand chose : il suffit de copier les fichiers de
configuration de la version précédente. Et bien sur reinstaller les
logiciels qu'on avait, ce qui se fait en une seule commande si on en
avait sauvegardé la liste avant.



Re: Mise à jour jessie --> buster

2019-07-12 Thread Eric Degenetais
Le ven. 12 juil. 2019 21:07, ajh-valmer  a écrit :

> > Le 12 juillet 2019 17:07:21 GMT+02:00, hamster a écrit :
> > >Oui bien sur, mais je n'ai pas parlé de danger, juste que c'est plus
> > >rapide de refaire l'install en partant de zero que de faire 2 upgrades.
>
> On Friday 12 July 2019 18:08:16 Gaëtan Perrier wrote:
> > Plus rapide ? Pour retrouver un environnement complètement
> > configuré et fonctionnel ça ne semble pas si évident que ça ...
> > Mais chacun fait comme il veut. :)
>
> Upgrade en 2 étapes est rapide, et on retrouve son environnement.
>
> Install en partant de zero, il faut recréer ensuite tout son environnement,
> ça risque de prendre plus de temps qu'un upgrade voire 2.
>
Mais il y a un risque supplémentaire de bizarreries, pouvant aller jusqu'à
des bugs... surtout en enchaînant deux migrations coup sur coup.
Donc configuration système propre vs reprise automatique de configuration,
ça dépendra sûrement des préférences personnelles (risques & gain de temps
ou lenteur & sûreté ? ).
La complexité de la configuration en jeu influencera sûrement...
J'avoue préférer préparer ma réinstallation sur une partition root
alternative (l'ancienne config restant intacte tant que je ne suis pas sûr
de la nouvelle), puis remonter ma home sur la nouvelle root, avec un point
de sauvegarde, quand je pense qu'elle est correcte.

Cordialement

>
>


Re: Wpa_supplicant Error: No such device

2019-07-12 Thread Patrick Bartek
On Fri, 12 Jul 2019 09:54:14 +0300
Andrei POPESCU  wrote:

> On Jo, 11 iul 19, 19:26:45, Patrick Bartek wrote:
> > On Thu, 11 Jul 2019 21:02:44 - (UTC)
> > Bert Riding  wrote:
> >   
> > > You could try using the actual device for the -i option 
> > > (interface)...like 
> > > wlan0 or, in the new notation wlp3s0, and use nl80122 as the -D 
> > > option (driver).  
> > 
> > iw dev or ip a report the device name to be wlx00e04c2a23c4.  This
> > designation never changes regardless of reboots or which USB port I
> > plug the wireless device into.  
> 
> That is a MAC-based name and is to be expected/makes sense for USB 
> adapters.

That's what I figured, too.

> > I examined the output of dmesg and noted that udev had reassigned 
> > wlan0 to this new name.  
> 
> To or from? I would expect the kernel to assign wlan0 to it and then 
> udev to rename it.

As I remember: FROM wlan0 TO wlx-etc.  And, yes, reassignment by udev.

B



Re: Wpa_supplicant Error: No such device

2019-07-12 Thread Patrick Bartek
On Fri, 12 Jul 2019 06:22:16 - (UTC)
Bert Riding  wrote:

> Yes, I'm sorry I didn't mention that my device name was merely an

Didn't have to.  I understood.  It's just wlan0 USED to be the default
1st wireless device, the last time I had to do this with another system
about 15 years ago, and I used it as a first test to bring UP the
device before reading the instructions. It failed, of course. Laziness.

> example.  I wonder if "ip link show" or "ls -l /sys/class/net" or the 
> obsolete "ifconfig a" give the same device name.  Udevadm might 
> help, too.  "udevadm info -e | grep .wl" for instance.  The name you are 
> using is the name using the MAC address, which is the last match as udev 
> lists the names, and won't be used if udev finds another name first.  See
> https://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/
>  

Here's what that all shows on my system (wireless parts only).
Wireless USB dongle plugged in, but otherwise dormant.

ip a

3: wlx00e04c2a23c4:  mtu 1500 qdisc noop state
DOWN mode DEFAULT group default qlen 1000 link/ether 00:e0:4c:2a:23:c4
brd ff:ff:ff:ff:ff:ff

ls -l /sys/class/net

lrwxrwxrwx 1 root root 0 Jul 12 07:48 wlx00e04c2a23c4
-> ../../devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4

/sbin/iw dev

phy#0
Interface wlx00e04c2a23c4
ifindex 3
wdev 0x1
addr 00:e0:4c:2a:23:c4
type managed
txpower 0.00 dBm

udevadm info -e | grep .wl

E: RFKILL_TYPE=wlan
P: /devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4
E:
DEVPATH=/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/net/wlx00e04c2a23c4
E: DEVTYPE=wlan E: ID_NET_NAME=wlp0s18f2u3
E: ID_NET_NAME_MAC=wlx00e04c2a23c4
E: ID_NET_NAME_PATH=wlp0s18f2u3
E: INTERFACE=wlx00e04c2a23c4
E:
SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlx00e04c2a23c4 
/sys/subsystem/net/devices/wlx00e04c2a23c4

As you can see, the wlx name is the only one that shows as far as I
can find. ifconfig is not installed.

FYI: systemd is not running on my system, except for udev.  When I
clean installed, I switched to sysvinit as the init as soon as I
could.

> "nl80211" is the correct name of the driver.  I apologize for the error.

An error, yes, but one I made a couple times myself during my trials to
get wireless working.

Thanks for the response.

B


> On Fri, 12 Jul 2019 04:30:02 +0200, Patrick Bartek wrote:
> 
> > On Thu, 11 Jul 2019 21:02:44 - (UTC)
> > Bert Riding  wrote:
> >   
> >> You could try using the actual device for the -i option (interface)...like 
> >> wlan0 or, in the new notation wlp3s0, and use nl80122 as the -D 
> >> option (driver).  
> > 
> > iw dev or ip a report the device name to be wlx00e04c2a23c4.  This
> > designation never changes regardless of reboots or which USB port I
> > plug the wireless device into. I examined the output of dmesg and noted
> > that udev had reassigned wlan0 to this new name. Don't know why.  And it
> > does work when scanning or finding device info or bringing device up or
> > down.  But I initially tried wlan0 anyway.  Got "No such
> > device . . ." etc.
> > 
> > I tried using -D nl80211 (did you transpose digits?) and not using it.
> > wpa_supplicant failed with the same error noted below.  Also, tried
> > wext. Ditto.
> > 
> > Haven't tried wlp3s0, but haven't found ANY reference to that name
> > on the system regardless of which command I use to show network devices.
> > 
> > Thanks for your input.
> > 
> > B
> >   
> >> On Thu, 11 Jul 2019 02:10:02 +0200, Patrick Bartek wrote:
> >>   
> >> > A problem when trying to associate with a wireless router
> >> > (WPA2). Get the following error when manually executing:
> >> > 
> >> > wpa_supplicant -i wlx
> >> > -c /etc/wpa_supplicant/wpa_supplicant.conf
> >> > 
> >> > Could not read interface wlx flags: No such device
> >> > nl80211: Driver does not support authentication/association or connect
> >> > commands
> >> > nl80122: [can't read my own writing on this one]
> >> > 
> >> > Wpa_supplicant fails whether I use the -B (background) switch or not.
> >> > 
> >> > Here's the wpa_supplicant.conf file:
> >> > 
> >> > 
> >> > ctrl_interface=DIR=/run/wpa_supplicant
> >> > update_config=1
> >> > 
> >> > network={
> >> >  ssid="ROUTERNAME"
> >> > #scan_ssid=1
> >> > #key_mgmt=WPA-PSK
> >> > #psk="SECRETPASSPHRASE"
> >> >  psk=longhexnumber
> >> > }
> >> > 
> >> > I've tried with and without the commented lines.  Same results.
> >> > 
> >> > Here's the wifi portion of my /etc/network/interfaces
> >> > 
> >> > allow-hotplug wlx
> >> > iface wlx inet dhcp
> >> >  wpa-ssid ROUTERNAME
> >> > #wpa-key-mgmt WPA-PSK
> >> > #wpa-group TKIP CCMP
> >> > #wpa-psk SECRETPASSPHRASE
> >> >  wpa-psk longhexnumber
> >> > 
> >> > The wireless is a Rosewill USB RNX-N180UBEv3. It is UP after boot and
> >> > scanning wifi routers works.  System tries to associate to router at
> >> 

Re: Mise à jour jessie --> buster

2019-07-12 Thread ajh-valmer
> Le 12 juillet 2019 17:07:21 GMT+02:00, hamster a écrit :
> >Oui bien sur, mais je n'ai pas parlé de danger, juste que c'est plus
> >rapide de refaire l'install en partant de zero que de faire 2 upgrades.

On Friday 12 July 2019 18:08:16 Gaëtan Perrier wrote:
> Plus rapide ? Pour retrouver un environnement complètement 
> configuré et fonctionnel ça ne semble pas si évident que ça ... 
> Mais chacun fait comme il veut. :)

Upgrade en 2 étapes est rapide, et on retrouve son environnement.

Install en partant de zero, il faut recréer ensuite tout son environnement,
ça risque de prendre plus de temps qu'un upgrade voire 2.



Re: Xfce4 Applications Appearance.

2019-07-12 Thread Stephen P. Molnar




On 07/12/2019 01:51 PM, Dan Ritter wrote:

Stephen P. Molnar wrote:

I have just installed Buster with the Xfce Desktop and am finding problems
with the appearance of some of the applications in tahat labels and icons
are run together.  I have attached a screenshot of the Pluma editor.

During the installation of Buster I didn't add any icon sets.

I did not encounter this problem is Stretch. What is the solution to this
problem?


With XFCE, you can use the settings manager to control:

- DPI for the monitor
- base system font size
- base system font
- icon set

Fonts and icons can be installed -- see packages named
*-icon-theme, or fonts-*.

Some change to these might be helpful.

-dsr-

I solved the problem by installing the RC2 and making sure that the 
installation is up to date.


Stephen P. Molnar, Ph.D.  Life is a fuzzy set
http://www.Molecular-Modeling.net Multivariate and stochastic
614.312.7528 (c)
Skype:  smolnar1



Re: Xfce4 Applications Appearance.

2019-07-12 Thread Dan Ritter
Stephen P. Molnar wrote: 
> I have just installed Buster with the Xfce Desktop and am finding problems
> with the appearance of some of the applications in tahat labels and icons
> are run together.  I have attached a screenshot of the Pluma editor.
> 
> During the installation of Buster I didn't add any icon sets.
> 
> I did not encounter this problem is Stretch. What is the solution to this
> problem?
> 

With XFCE, you can use the settings manager to control:

- DPI for the monitor
- base system font size
- base system font
- icon set

Fonts and icons can be installed -- see packages named
*-icon-theme, or fonts-*.

Some change to these might be helpful.

-dsr-



Re: Don't disable recoomends by default

2019-07-12 Thread Brian
On Fri 12 Jul 2019 at 20:21:08 +0300, Reco wrote:

>   Hi.
> 
> On Fri, Jul 12, 2019 at 12:24:49PM -0300, Jonas Smedegaard wrote:
> > Quoting Reco (2019-07-12 09:34:17)
> > > On Fri, Jul 12, 2019 at 09:13:29AM -0300, Jonas Smedegaard wrote:
> > > > Quoting Reco (2019-07-12 09:01:33)
> > > > > > > Disabling installing Recommends by default also helps a great 
> > > > > > > deal with all those dependencies you don't want.
> > > > > > 
> > > > > > Above may break your system in confusing to debug ways,
> > > > > 
> > > > > Rly? Recommends are called that for a reason.
> > > > 
> > > > Yes, and the reason is well defined: Packages requires in "all but 
> > > > unusual installations." - quoted from Debian Policy §7.2.
> > > 
> > > This only shows us that one can prove anything by using selective 
> > > quoting. Full quote, btw is:
> > > 
> > > This declares a strong, but not absolute, dependency.
> > > The Recommends field should list packages that would be found together
> > > with this one in all but unusual installations.
> > > 
> > > 
> > > Therefore Debian Policy explicitly says that Recommends are not
> > > required.
> > 
> > Sorry if you feel that I mislead you by quoting narrowly.
> > I fail to recognize how your larger quote changes my point of mine,
> > however.
> 
> I see nothing to apologise for. You made some bold claims, I showed they
> do not universally apply. Each of us stayed at their respective
> opinions, let's leave it at that.
> 
> > Indeed Debian policy do not _require_ recommendations.  They do however 
> > recommend to install them except in unusual installations.
> > Turning off recommendations is saying "this system is unusual in all 
> > possible ways" which I insist is wrong and bad advice!
> 
> And the key word here is "recommend".
> One of the biggest strengths in the Free Software lies in the putting
> the user in control.

Fine.

> Mandating to install certain software, assuming that there's only one
> "right" way of doing things, using scare tactics like "system is
> unusual" - this reeks of non-free software from world-known commercial
> entities, and limiting the control of the user over their software.

I do not think any of that diatribe is the intention of Policy.

> I say - if the user wants to "break" a system by not installing the
> Recommends - let them. Whenever it's curiosity, a way of learning
> something new or just a wish to do an OS liposuction.
> Either way it won't break (a hint - Recommends weren't always the
> default), or the user will learn something new in a process.

That's fine too.
 
> Besides, they don't call Debian the Universal OS for nothing. It can
> tolerate the surprising amount of "breakage".

mc recommends unzip. The OS will get along perfectly well without it.
It's the user who who has to tolerate the breakage.

-- 
Brian.
> 
> Reco
> 



Xfce4 Applications Appearance.

2019-07-12 Thread Stephen P. Molnar
I have just installed Buster with the Xfce Desktop and am finding 
problems with the appearance of some of the applications in tahat labels 
and icons are run together.  I have attached a screenshot of the Pluma 
editor.


During the installation of Buster I didn't add any icon sets.

I did not encounter this problem is Stretch. What is the solution to 
this problem?


Thanks in advance.

--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
http://www.Molecular-Modeling.net   Multivariate and stochastic
614.312.7528 (c)
Skype:  smolnar1



Re: Don't disable recoomends by default

2019-07-12 Thread Reco
Hi.

On Fri, Jul 12, 2019 at 12:24:49PM -0300, Jonas Smedegaard wrote:
> Quoting Reco (2019-07-12 09:34:17)
> > On Fri, Jul 12, 2019 at 09:13:29AM -0300, Jonas Smedegaard wrote:
> > > Quoting Reco (2019-07-12 09:01:33)
> > > > > > Disabling installing Recommends by default also helps a great 
> > > > > > deal with all those dependencies you don't want.
> > > > > 
> > > > > Above may break your system in confusing to debug ways,
> > > > 
> > > > Rly? Recommends are called that for a reason.
> > > 
> > > Yes, and the reason is well defined: Packages requires in "all but 
> > > unusual installations." - quoted from Debian Policy §7.2.
> > 
> > This only shows us that one can prove anything by using selective 
> > quoting. Full quote, btw is:
> > 
> > This declares a strong, but not absolute, dependency.
> > The Recommends field should list packages that would be found together
> > with this one in all but unusual installations.
> > 
> > 
> > Therefore Debian Policy explicitly says that Recommends are not
> > required.
> 
> Sorry if you feel that I mislead you by quoting narrowly.
> I fail to recognize how your larger quote changes my point of mine,
> however.

I see nothing to apologise for. You made some bold claims, I showed they
do not universally apply. Each of us stayed at their respective
opinions, let's leave it at that.


> Indeed Debian policy do not _require_ recommendations.  They do however 
> recommend to install them except in unusual installations.
> Turning off recommendations is saying "this system is unusual in all 
> possible ways" which I insist is wrong and bad advice!

And the key word here is "recommend".
One of the biggest strengths in the Free Software lies in the putting
the user in control.
Mandating to install certain software, assuming that there's only one
"right" way of doing things, using scare tactics like "system is
unusual" - this reeks of non-free software from world-known commercial
entities, and limiting the control of the user over their software.

I say - if the user wants to "break" a system by not installing the
Recommends - let them. Whenever it's curiosity, a way of learning
something new or just a wish to do an OS liposuction.
Either way it won't break (a hint - Recommends weren't always the
default), or the user will learn something new in a process.

Besides, they don't call Debian the Universal OS for nothing. It can
tolerate the surprising amount of "breakage".

Reco



Re: Don't disable recoomends by default

2019-07-12 Thread Brian
On Fri 12 Jul 2019 at 12:24:49 -0300, Jonas Smedegaard wrote:

> Quoting Reco (2019-07-12 09:34:17)
> > On Fri, Jul 12, 2019 at 09:13:29AM -0300, Jonas Smedegaard wrote:
> > > Quoting Reco (2019-07-12 09:01:33)
> > > > > > Disabling installing Recommends by default also helps a great 
> > > > > > deal with all those dependencies you don't want.
> > > > > 
> > > > > Above may break your system in confusing to debug ways,
> > > > 
> > > > Rly? Recommends are called that for a reason.
> > > 
> > > Yes, and the reason is well defined: Packages requires in "all but 
> > > unusual installations." - quoted from Debian Policy §7.2.
> > 
> > This only shows us that one can prove anything by using selective 
> > quoting. Full quote, btw is:
> > 
> > This declares a strong, but not absolute, dependency.
> > The Recommends field should list packages that would be found together
> > with this one in all but unusual installations.
> > 
> > 
> > Therefore Debian Policy explicitly says that Recommends are not
> > required.
> 
> Sorry if you feel that I mislead you by quoting narrowly. I fail to 
> recognize how your larger quote changes my point of mine, however.
> 
> Indeed Debian policy do not _require_ recommendations.  They do however 
> recommend to install them except in unusual installations.
> 
> Turning off recommendations is saying "this system is unusual in all 
> possible ways" which I insist is wrong and bad advice!

I would like to bore everyone with my activities over the past few days.
There is a thin client; it has one task to do and has 945M of disk space
to do it in. Try it sometime.

I have to carefully read the outputs of 'apt show' and test. The default
package installation is with --no-install-recommends. Tedious and time-
consuming, but I get what I want. Miss a recommendation and I'm stuffed.

Are you an average user? Lots of disk space? Want a trouble-free system?
Stick with the default installing recommended packages advice.

-- 
Brian.



Re: [Off-topic]

2019-07-12 Thread Reco
Hi.

On Fri, Jul 12, 2019 at 08:52:57AM -0500, John Hasler wrote:
> > To me, Bigcorp is like state (minus First Amendment).
> 
> Businesses don't have armies.

Or do they?

https://en.wikipedia.org/wiki/Blackwater_Worldwide

Reco



Re: Don't disable recoomends by default

2019-07-12 Thread Brian
On Fri 12 Jul 2019 at 11:23:56 -0400, Dan Ritter wrote:

> Jonas Smedegaard wrote: 
> > Quoting Stephan Seitz (2019-07-12 09:30:38)
> > > On Fr, Jul 12, 2019 at 09:13:29 -0300, Jonas Smedegaard wrote:
> > > >Wrong.  Suggests are for packages useful only "sometimes", recommends
> > > >are for pacakges needed in "all but unusual installations."
> > > 
> > > From my experience this is wrong.
> > > 
> > > With recommends my d10 update would have systemd as init instead of 
> > > sysvinit. And I would have got (for example) the package debsecan 
> > > which I don’t need.
> > > 
> > > So it is better to disable recommends and look at the recommended 
> > > packages.
> > 
> > There is nothing wrong in suppressing specific recommendations where you 
> > understand the implications.
> > 
> > What is wrong is to suppress all recommendations by default.
> 
> There's nothing wrong with suppressing all recommendations by
> default, as long as you're willing to go back in and install
> particular packages when you realize you want what they do.

I'll go along with Jonas Smedegaard's advice. When a user knows what
he is doing, not installing Recommends: is the result of a deliberate
and considered decision. If the user makes not having recommended
packages the default on his system, I can assure you (having done it)
that realisation sometimes comes at a substantial price, especially
when more than one package is involved.

The average user loses nothing by ignoring suggestions not to install
Recommends: across the board. They will be happier with their Debian
system - and that is what we all want, eh?

-- 
Brian.




Re: Repositório Debian Testing 11

2019-07-12 Thread Linux - Junior Polegato

Em 11/07/2019 20:05, Jack Jr. escreveu:
Apareceu o nome do Repositório Security do Testing 11 que eu estava 
procurando



Agora
deb http://security.debian.org/debian-security bullseye-security main


Jack Pogorelsky Jr.
Engenheiro Mecânico
Tel/WhatsApp: +55 (51) 982017877
E-mail: j...@sulmail.com
Website: sulmail.com/pogorelsky



 Mensagem encaminhada 
Assunto: 	Suite name for security updates changing with Debian 11 
"bullseye"

Resent-Date:Thu, 11 Jul 2019 20:01:51 + (UTC)
Resent-From:debian-devel-annou...@lists.debian.org
Data:   Thu, 11 Jul 2019 22:01:01 +0200
De: Ansgar Burchardt 
Para:   debian-devel-annou...@lists.debian.org



Hi,

over the last years we had people getting confused over -updates
(recommended updates) and /updates (security updates). Starting
with Debian 11 "bullseye" we have therefore renamed the suite including
the security updates to -security.

An entry in sources.list should look like

deb http://security.debian.org/debian-security bullseye-security main

For previous releases the name will not change.

Ansgar



Olá!

        Tal como relatado, antes era testing/updates, agora passou a 
ser testing-security ;-)


--

[]'s

Junior Polegato



Re: Mise à jour jessie --> buster

2019-07-12 Thread Gaëtan Perrier
Plus rapide ? Pour retrouver un environnement complètement configuré et 
fonctionnel ça ne semble pas si évident que ça ...
Mais chacun fait comme il veut. :)

Le 12 juillet 2019 17:07:21 GMT+02:00, hamster  a écrit :
>Le 12/07/2019 à 14:48, ajh-valmer a écrit :
>> On Friday 12 July 2019 12:33:31 hamster wrote:
>>> Le 12/07/2019 à 11:56, Francois Meyer a écrit :
 J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il
>mieux
 passer par Stretch ou sauter directement à Buster d'après vous ?
>>> Il n'est pas du tout recommandé de sauter une version dans les mise
>a
>>> jour de distrib.
>>> De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les
>suivant
>>> dans le fil, sur un poste de travail je préfère refaire l'install
>plutot
>>> que mettre a jour, alors a fortiori si tu a une version de retard.
>> Non, on peut parfaitement upgrader sans danger
>
>Oui bien sur, mais je n'ai pas parlé de danger, juste que c'est plus
>rapide de refaire l'install en partant de zero que de faire 2 upgrades.

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Black screen after fresh install of buster

2019-07-12 Thread Daniel Harris
Just for the record, reluctantly I installed the nvidia drivers from
non-free and all is now working perfectly but I would like to use the *nouveau
drivers.  Why they are not working when they worked perfectly in the
previous stable version of debian?*


*Dan*

On Thu, Jul 11, 2019 at 6:57 PM Daniel Harris 
wrote:

>
>
> On Thu, Jul 11, 2019 at 5:24 PM Felix Miata  wrote:
>
>> Daniel Harris composed on 2019-07-11 15:39 (UTC+0100):
>>
>> > Need some help.  My screen goes black if login to any other desktop
>> > environment other than Gnome, even gnome-xorg only shows a black screen.
>>
>> > I have a nvidia graphics card but i am only using standard debian, no
>> > non-free repos.
>>
>> > Can anybody help as i have not played around with the os so not sure
>> how to
>> > debug this.
>>
>> Please share Xorg.0.log from an attempted Xorg session, either in
>> /var/log/ or in
>> ~/.local/share/xorg/. If this is a problem, at least share content of
>> /proc/cmdline, which the log includes.
>>
>
> BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
> root=UUID=6554b9db-39d6-4b8e-8092-0ecc91d67273 ro quiet
>
> Successful Gnome login log
>
> [   228.974] (II) systemd-logind: releasing fd for 13:64
> [   228.987] (II) UnloadModule: "libinput"
> [   228.987] (II) systemd-logind: releasing fd for 13:65
> [   229.003] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error
> [   229.003] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error
> [   229.003] (WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error
> [   229.003] (II) Server terminated successfully (0). Closing log file.
>
> Failed login to Xfce
>
> [   394.914] (II) AIGLX: Suspending AIGLX clients for VT switch
> [   394.981] (II) systemd-logind: got pause for 226:0
> [   394.981] (II) systemd-logind: got pause for 13:64
> [   394.981] (II) systemd-logind: got pause for 13:67
> [   394.981] (II) systemd-logind: got pause for 13:65
> [   394.981] (II) systemd-logind: got pause for 13:66
> [   394.981] (II) systemd-logind: got pause for 13:68
> [   394.981] (II) systemd-logind: got pause for 13:69
>
> Hangs after this point
>
>
>>
>> How old is your NVidia/what model? Output from 'inxi -GxxS' in Gnome
>> would do for
>> this. A very new model might require a non-FOSS driver from NVidia.
>>
>
>  System:
>   Host: gaming Kernel: 4.19.0-5-amd64 x86_64 bits: 64 compiler: gcc v:
> 8.3.0
>   Desktop: Gnome 3.30.2 wm: gnome-shell dm: GDM3
>   Distro: Debian GNU/Linux 10 (buster)
> Graphics:
>   Device-1: NVIDIA G94 [GeForce 9600 GT] vendor: Gigabyte driver: nouveau
>   v: kernel bus ID: 01:00.0 chip ID: 10de:0622
>   Display: wayland server: X.org 1.20.4 driver: nouveau compositor:
> gnome-shell
>   tty: 86x26
>   Message: Advanced graphics data unavailable for root.
>
>
>> If xserver-xorg-video-nouveau is installed, try installing it. If it is
>> not, try
>> purging it.
>>
>> Installed
>
>
>> It may be that you don't have non-free repos installed, and need to in
>> order to
>> obtain firmware your NVidia requires.
>>
>> If i can I would like to avoid non-free
>
>
>> It's possible disabling plymouth could impact this. Either purge it, or
>> add
>> plymouth.enable=0 to Grub's linux line to find out.
>>
>
> No Change
>
>>
>> Which installation type do you have, legacy/MBR, or UEFI?
>>
>
> legacy/MBR
>
>> --
>> Evolution as taught in public schools is religion, not science.
>>
>>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
>>
>> Felix Miata  ***  http://fm.no-ip.com/
>
>
> I have had the system running Stretch for years with no problem.  Did an
> upgrade and blank screen started so I did a fresh install and the blank
> screen happened straight away.
> Hope someone can help.
>
> Thanks
>
>
> Dan
>
>
>


Re: systemd-container login as root no longer possible?

2019-07-12 Thread Ulf Volmer
On 12.07.19 03:20, arne wrote:

> # machinectl login mycontainer
> 
> gives me a login screen
> 
> When I enter "root"
> no password prompt is shown

Did you checked /etc/securetty in your container? This is the most
common cause for this kind of error.

Best regards
Ulf



Re: Don't disable recoomends by default

2019-07-12 Thread Jonas Smedegaard
Quoting Reco (2019-07-12 09:34:17)
> On Fri, Jul 12, 2019 at 09:13:29AM -0300, Jonas Smedegaard wrote:
> > Quoting Reco (2019-07-12 09:01:33)
> > > > > Disabling installing Recommends by default also helps a great 
> > > > > deal with all those dependencies you don't want.
> > > > 
> > > > Above may break your system in confusing to debug ways,
> > > 
> > > Rly? Recommends are called that for a reason.
> > 
> > Yes, and the reason is well defined: Packages requires in "all but 
> > unusual installations." - quoted from Debian Policy §7.2.
> 
> This only shows us that one can prove anything by using selective 
> quoting. Full quote, btw is:
> 
> This declares a strong, but not absolute, dependency.
> The Recommends field should list packages that would be found together
> with this one in all but unusual installations.
> 
> 
> Therefore Debian Policy explicitly says that Recommends are not
> required.

Sorry if you feel that I mislead you by quoting narrowly. I fail to 
recognize how your larger quote changes my point of mine, however.

Indeed Debian policy do not _require_ recommendations.  They do however 
recommend to install them except in unusual installations.

Turning off recommendations is saying "this system is unusual in all 
possible ways" which I insist is wrong and bad advice!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Re: Don't disable recoomends by default

2019-07-12 Thread Dan Ritter
Jonas Smedegaard wrote: 
> Quoting Stephan Seitz (2019-07-12 09:30:38)
> > On Fr, Jul 12, 2019 at 09:13:29 -0300, Jonas Smedegaard wrote:
> > >Wrong.  Suggests are for packages useful only "sometimes", recommends
> > >are for pacakges needed in "all but unusual installations."
> > 
> > From my experience this is wrong.
> > 
> > With recommends my d10 update would have systemd as init instead of 
> > sysvinit. And I would have got (for example) the package debsecan 
> > which I don’t need.
> > 
> > So it is better to disable recommends and look at the recommended 
> > packages.
> 
> There is nothing wrong in suppressing specific recommendations where you 
> understand the implications.
> 
> What is wrong is to suppress all recommendations by default.

There's nothing wrong with suppressing all recommendations by
default, as long as you're willing to go back in and install
particular packages when you realize you want what they do.

-dsr-



Re: Don't disable recoomends by default

2019-07-12 Thread Jonas Smedegaard
Quoting Stephan Seitz (2019-07-12 09:30:38)
> On Fr, Jul 12, 2019 at 09:13:29 -0300, Jonas Smedegaard wrote:
> >Wrong.  Suggests are for packages useful only "sometimes", recommends
> >are for pacakges needed in "all but unusual installations."
> 
> From my experience this is wrong.
> 
> With recommends my d10 update would have systemd as init instead of 
> sysvinit. And I would have got (for example) the package debsecan 
> which I don’t need.
> 
> So it is better to disable recommends and look at the recommended 
> packages.

There is nothing wrong in suppressing specific recommendations where you 
understand the implications.

What is wrong is to suppress all recommendations by default.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Re: Mise à jour jessie --> buster

2019-07-12 Thread hamster
Le 12/07/2019 à 14:48, ajh-valmer a écrit :
> On Friday 12 July 2019 12:33:31 hamster wrote:
>> Le 12/07/2019 à 11:56, Francois Meyer a écrit :
>>> J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il mieux
>>> passer par Stretch ou sauter directement à Buster d'après vous ?
>> Il n'est pas du tout recommandé de sauter une version dans les mise a
>> jour de distrib.
>> De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les suivant
>> dans le fil, sur un poste de travail je préfère refaire l'install plutot
>> que mettre a jour, alors a fortiori si tu a une version de retard.
> Non, on peut parfaitement upgrader sans danger

Oui bien sur, mais je n'ai pas parlé de danger, juste que c'est plus
rapide de refaire l'install en partant de zero que de faire 2 upgrades.



Re: (deb-cat) Alerta amb gnome-disk-utility

2019-07-12 Thread Narcis Garcia
__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 8/7/19 a les 9:46, Alex Muntada ha escrit:
> Hola Narcis,
> 
>> Molt important (importantíssim) per qui utilitza volums xifrats:
>> https://bugs.debian.org/928893
> 
> M'hi he subscrit, mil gràcies!
> 
>> Si utilitzeu l'eina gràfica «Discs» per a canviar la contrasenya
>> d'un volum xifrat, no ho feu amb Debian 10 fins que l'esmentada
>> incidència estigui resolta i ho tingueu actualitzat:
>> La versió 3.30 d'aquesta aplicació, quan se li demana canviar la
>> frase de pas d'un volum xifrat (com al disc dur o a una memòria
>> USB), elimina l'anterior contrasenya i no n'estableix cap de
>> nova.
>>
>> Això pot implicar que ja no es pugui accedir mai més a les dades
>> xifrades!
> 
> Fa uns anys, tornant de vacances vaig oblidar la contrasenya de
> xifrat del disc de la feina. Vaig estar una setmana per adonar-me
> que l'estava posant malament (gairebé reinstal·lo l'ordinador),
> mentre treballava amb el meu portàtil.
> 
> Una cosa que vaig descobrir durant aquella setmana és que es pot
> fer una còpia de les metadades de xifrat, que es poden utilitzar
> després en cas que s'hagin corromput o no recordis la contrasenya
> o deixi de funcionar. Els detalls són al man del cryptsetup
> (luksDump i luksHeaderBackup).

Alguns detalls més:
1. El problema només passa amb LUKS2, i no pas amb LUKS1.
gnome-disks a la Debian 10 formata LUKS1 de forma predeterminada, així
que no hi ha problema amb els volums que s'hagin xifrat amb versions
anteriors de Debian o el mateix gnome-disks.

2. És el DebianInstaller el què formata LUKS2 de manera predeterminada
quan demanes xifrat en instal·lar Debian 10 de nou. I això no té marxa
enrere (cryptsetup preveu la conversió d'algunes LUKS2 a LUKS1 però ja
ho he provat amb la partició de sistema creada per DebianInstaller i no
es pot).
Això vol dir que el desastre es produeix bàsicament en intentar canviar
la contrasenya de xifrat d'una partició creada amb l'instal·lador de
Debian 10. També, és clar, amb volums creats amb altre programari que
seleccioni LUKS2.



Re: Debian 10

2019-07-12 Thread Gonzalo Rivero
El jue, 11-07-2019 a las 13:24 -0300, Marcelo Eduardo Giordano
escribió:
> Amigos.
> 
> Tengo entendido que Debian 10 ya es estable. Es cierto? 
si

> Ya lo podemos 
> instalar?
> 

no sin leer antes las notas de publicación para estar prevenido de todo
lo que podría salir mal: 
https://www.debian.org/releases/stable/releasenotes




Re: Where'd lsb-compat go?

2019-07-12 Thread Kent West



On 7/11/19 10:04 PM, Dominic Knight wrote:

On Thu, 2019-07-11 at 13:48 -0500, Kent West wrote:

Two issues:


1) I have several Debian boxes running as kiosks, and reporting to a
centralized Quest-branded "Systems Management Appliance" (SMA). With
a
recent update to the SMA, the Debian boxes stopped reporting in.
After
several weeks, I finally discovered that the installation of
"lsb-compat" on several of them restored their functionality. Today,
when I go to install "lsb-compat" on the other's, I find it's no
longer
available in Buster. Has it been deprecated? Why? Any ideas how I'm
going to get my boxes reporting again to the SMA (what does "lsb-
compat"

**
The Linux Standard Base (http://www.linuxbase.org/) was a standard
core system that third-party applications written for Linux could
depend upon.

This package provides the most minimal layer to be able to install and
run selected legacy LSB packages on Debian.
**

(untested) Maybe temporarily set your sources to old stable or stretch
and pick it up from there (then reset them of course).

I could only guess when you installed on the other boxes it was set to
stable (stretch) which was then stable but is now buster.



Okay, I've learned something about aptitude.

I added "oldstable" and after an "aptitude update", the older lsb stuff 
became available with an "aptitude search lsb", and I installed 
"lsb-compat". And when I removed "oldstable" and did another "aptitude 
update", the old lsb stuff was still available. That surprised me; I 
thought "aptitude search" would show what was available for downloading, 
but I guess it needs to also remember what is currently installed. And 
if I purge "lsb-compat" and then do another "aptitude search lsb", sure 
enough, the old stuff is now not shown.


Interesting

So that answers my issue #2.

Back to issue #1:

When I updated the working machine to my current "stable" sources.list, 
the version of Debian on that box went from 9.9 to 10, and even though 
"lsb-compat" remained installed, the communication with my Quest server 
has again gone silent. So apparently I don't need to know what 
lsb-compat does, or how to duplicate that functionality in some way now 
that lsb-compat is (apparently) deprecated, because the problem seems to 
be deeper than that. Although something changed between version 9.9 with 
lsb-compat and version 10 with lsb-compat, that's too general of an 
issue to ask about on this list; I'll have to narrow down more 
specifically what the Quest server is looking for (unless someone just 
knows what might have changed between the two versions that might have 
affected a third-party in this way - not likely).


And finally, yeah, I normally track release names ("potato", "buster", 
etc) in my sources.list files, but for some reason the working machine 
was tracking "stable", so I modified the non-working machine from 
"stretch" to "stable" to make the two machines more similar. I'm 
generally wary of the potential of upgrading to a new version by accident.


Thanks, all!

--

Kent




Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

2019-07-12 Thread G2PC

> Noter que le serveur ici acceptait en effet la connexion par mot de
> passe, ce qui est une mauvaise idée, mais, j'en était au début de sa
> configuration. Entre temps, j'ai interdit la connexion par mot de
> passe.
>
> J'étais donc justement entrain de reprendre mes différents tutoriels
> pour les éprouver lors d'une installation standard.
> J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison.
>
> Cette installation m'a permis d'être confronté à cette
> problématique de
> droits, pour mes propres clés, et, de ce bogue ( manque
> d'informations )
> pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits.
>
>
> il faut tenir compte ici du fait que celui qui se connecte n'est pas
> forcément un utilisateur légitime à qui on a envie de fournir des
> informations sur la configuration du serveur cible. 
> Le message concernant la clef est plus à sa place dans les logs du
> serveur.


Effectivement, on peut aussi le voir comme ça, pourtant, si une personne
tente de se connecter avec une clé, c'est qu'il a déjà la clé ...
Dès lors, si la clé est la bonne ou qu'elle ne le soit pas d'ailleurs,
le programme SSH et SSHFS peut nous informer que nous en faisons un
mauvais usage, au niveau des droits appliqués à la clé.

Je pense que cette alerte, notamment pour les débutants, est importante.
Devoir la retrouver dans les logs ne me semble pas approprié, enfin, il
serait bien plus pratique, pour les débutants et même pour les
confirmés, d'être informé directement en console, en cas d'erreur de
droits sur la clé privée SSH.



Re: [Off-topic]

2019-07-12 Thread tomas
On Fri, Jul 12, 2019 at 08:52:57AM -0500, John Hasler wrote:
> tomas writes:
> > You can't easily monetize mail (the interfaces are standard, for a
> > consumer it's easy to change providers)
> 
> Gmail.  The only interface that matters to most people is the user
> interface they see in their browser and that is not standardized.
> 
> > I have the impression you're being blindsided by ideology there.
> 
> I don't suffer from that disease (which is pretty much the same as
> religion).

Famous Last Words (TM).

> > To me, Bigcorp is like state (minus First Amendment).
> 
> Businesses don't have armies.

Says who?

> > I had early and intense religious education.  Not trying to offend
> > anyone, but I had my share of devil and then some. These days I prefer
> > to make do without
> 
> If you still believe in evil you haven't entirely overcome your
> religious indoctrination.

Of course I don't believe in "evil". What's there to believe in?
Still there are actions I'd describe as evil. It's a useful
adjective, as are "red" or "bitter" or "tenuous".

Cheers
-- t


signature.asc
Description: Digital signature


[Off-topic]

2019-07-12 Thread John Hasler
tomas writes:
> You can't easily monetize mail (the interfaces are standard, for a
> consumer it's easy to change providers)

Gmail.  The only interface that matters to most people is the user
interface they see in their browser and that is not standardized.

> I have the impression you're being blindsided by ideology there.

I don't suffer from that disease (which is pretty much the same as
religion).

> To me, Bigcorp is like state (minus First Amendment).

Businesses don't have armies.

> I had early and intense religious education.  Not trying to offend
> anyone, but I had my share of devil and then some. These days I prefer
> to make do without

If you still believe in evil you haven't entirely overcome your
religious indoctrination.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA



Re: Minimial Live Image

2019-07-12 Thread Peter Ehlert



On 7/12/19 1:38 AM, Rick Thomas wrote:



On Jul 11, 2019, at 11:06 AM, J.Arun Mani  wrote:

Hi

Im planning to install Debian in my (already Linux Mint powered) laptop. But 
the ISO size is huge (~2.7 GB), something beyond my per-day bandwidth limit of 
1.5 GB (actually 2 GB, but .5 GB is spent in other personal things). And I also 
found that Debian ships with a large pack of softwares and does not have 
(official) support for propertiary drivers.

So what I want is a live bootable minimial ISO with a DE (a basic one is enough 
if DEs can be changed easily later) and a basic set of packages with support 
for propertiary drivers (is there anyother way to get it if Debian doesn't 
provide it officially ?).

My dear friends, help me, where can I find such ISOs? (No Netinst or Network 
boot, because of my Internet speed and other issues)

Nice day :)
J Arun Mani

Hi!

I found this [1] 1.3GB image.  (“standard” = no DE, just text console.  But you 
can add any DE you want later with “sudo tasksel”.)  That’s just barely under 
your stated daily bandwidth allowance of 1.5GB.  Everything else (the images 
that include a DE GUI) is hovering around 2.5GB.
actually the "standard" does install a desktop, it is some sort of Gnome 
Lite.


I made the mistake of not deselecting it (DVD install) a day or two ago 
and ended up with a very odd desktop that that did not include Synaptic.
After finding the "software store" I got Synaptic installed but it had 
something that conflicted so it did not operate correctly.


I finally discovered that if I logout and then login it there were 
several options options,

one was *system X11 default*.
choosing that I was able to run Synaptic and proceed with installing Mate.

I suspect it has something to do with Wayland as dictated by Gnome

You can also get it from bittorrent at [2].  Bittorrent is recommended if you 
have a choice, because it minimizes the load on the debian.org servers.

Hope it helps!

Rick

[1] 
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/10.0.0-live+nonfree/amd64/iso-hybrid/debian-live-10.0.0-amd64-standard+nonfree.iso

[2] 
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/10.0.0-live+nonfree/amd64/bt-hybrid/debian-live-10.0.0-amd64-standard+nonfree.iso.torrent






Re: [SOLVED] tailf vs buster

2019-07-12 Thread Reco
On Fri, Jul 12, 2019 at 08:46:19AM -0400, Greg Wooledge wrote:
> On Fri, Jul 12, 2019 at 11:35:20AM +0300, Reco wrote:
> > I don't dispute that RedHat did a lot of good things - good chunks of
> > the libc, gcc and a kernel itself is wrote by them.
> > On the other side though we have some really controversial things like
> > SecureBoot support, Wayland, GTK3, xfs, and s*d.
> 
> XFS was developed by SGI, not by Red Hat.

Yet it's their favorite toy now, and have been for at least for the last
decade. And "problematic" does not even start to describe this
particular filesystem as of now.
But I'm an optimist. Give it ten more years and maybe something good
will come out of it.


> There's some stuff about Red Hat in subsequent paragraphs, and it
> definitely does not paint a pretty picture of Red Hat.  If wikipedia is
> to be believed, Red Hat added partial XFS support 7 years after Gentoo,
> and then charged its customers extra money for the basic command line
> tools.  (And then possibly stopped being evil a few years after that.
> It's a little unclear.)

I was not aware of this little tidbit, but it sounds like very thing
RedHat would do.
For me it was enough that they made xfs the default one (some can say
"forced", but note that I didn't say it) and they *knew* that xfs will
lead to data loss if used without battery-backed storage.


> I'm not sure exactly what you consider "controversial" about XFS.  It's
> just a file system that you can choose to use, or not.

Random slowdowns for no good reason. Data loss on power failure. Kernel
panics at xfs-specific parts of the kernel just because.
Saw a lot of such stuff. The solution was the same every time - fsck it
(ambiguity is intentional here), we're moving survived data to ext4.


Now, ext4 is not without its problems too. But it's the scale of such
problems that matters.

Reco



Re: Mise à jour jessie --> buster

2019-07-12 Thread ajh-valmer
On Friday 12 July 2019 12:33:31 hamster wrote:
> Le 12/07/2019 à 11:56, Francois Meyer a écrit :
> > J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il mieux
> > passer par Stretch ou sauter directement à Buster d'après vous ?
> 
> Il n'est pas du tout recommandé de sauter une version dans les mise a
> jour de distrib.
> De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les suivant
> dans le fil, sur un poste de travail je préfère refaire l'install plutot
> que mettre a jour, alors a fortiori si tu a une version de retard.

Non, on peut parfaitement upgrader sans danger,
si on respecte en 2 étapes :
Jessie vers Stretch et Stretch ver Buster,
en le faisant en mode "recovery".

Surtout, ne pas oublier de rebooter à chaque étape,
en regardant les éventuels messages d'erreur.

Conseil : commencer par Jessie vers Stretch,
attendre un mois après la sortie de Buster (released),
pour la 2ème étape (après les défauts inhérents résolus).

A. Valmer



Re: Repair Grumb (grub)

2019-07-12 Thread Jimmy Johnson

On 7/12/19 3:08 AM, Stephen P. Molnar wrote:

Plese see responses to questions. .  .  .  .

On 07/11/2019 11:16 PM, David wrote:
On Fri, 12 Jul 2019 at 05:09, Stephen P. Molnar 
 wrote:

I have Stretch installed  on sda1 and Buster installed on sdd1 on my
64bit Linux platform.

Unfortunately, grub on sdd1 became corrupted and the boot process fails
after Buster is selected.

Everyone reading this wonders:
1) why are you hiding the most important facts in your question?
2) what exact symptoms cause you to conclude that "grub on sdd1 became
 corrupted"?

After allowing choice of Buster the boot hung with a '>' prompt.


AMD computers and complete buster update with wayland cause problems 
like x not starting or sometimes the user space will freeze with only 
background service running, input device's stop working. I don't know 
the fix.

--
Jimmy Johnson

Slackware 14.2 - KDE 4.14.32 - EXT4 at sda5
Registered Linux User #380263



Re: [SOLVED] tailf vs buster

2019-07-12 Thread Greg Wooledge
On Fri, Jul 12, 2019 at 11:35:20AM +0300, Reco wrote:
> I don't dispute that RedHat did a lot of good things - good chunks of
> the libc, gcc and a kernel itself is wrote by them.
> On the other side though we have some really controversial things like
> SecureBoot support, Wayland, GTK3, xfs, and s*d.

XFS was developed by SGI, not by Red Hat.  According to wikipedia:

  Initial support for XFS in the Linux kernel came through patches from
  SGI. It merged into the Linux kernel mainline for the 2.6 series,
  and separately merged in February 2004 into the 2.4 series in
  version 2.4.25,[10] making XFS almost universally available on Linux
  systems.[11] Gentoo Linux became the first Linux distribution to
  introduce an option for XFS as the default filesystem in mid-2002.[12]

There's some stuff about Red Hat in subsequent paragraphs, and it
definitely does not paint a pretty picture of Red Hat.  If wikipedia is
to be believed, Red Hat added partial XFS support 7 years after Gentoo,
and then charged its customers extra money for the basic command line
tools.  (And then possibly stopped being evil a few years after that.
It's a little unclear.)

I'm not sure exactly what you consider "controversial" about XFS.  It's
just a file system that you can choose to use, or not.



Re: memory fault after "cd xxx"

2019-07-12 Thread Pierre Frenkiel

On Thu, 11 Jul 2019, Nicholas Geovanis wrote:


Hmmm. How about checking your RAM , a memtest.


thanks for your answer, but meanwhile, I upgraded fron  Stretch to Buster,
and the problem disappeared...
I don't know whether the fix comes from the upgrade, or just the reboot...

best regards,
--
Pierre Frenkiel



Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

2019-07-12 Thread Eric Degenetais
Désolé, pour le bruit, j'ai eu un coup de mou ...
bien entendu nous sommes là côté client => effectivement il n'est pas
normal de ne pas donner la raison exacte du refus de la clef et de la
bascule sur mot de passe (ou du refus d'authentification).

Cordialement

Éric Dégenètais

__
Éric Dégenètais
Henix

http://www.henix.com
http://www.squashtest.org



Le ven. 12 juil. 2019 à 13:54, Eric Degenetais  a écrit :
>
> Le ven. 12 juil. 2019 13:04, G2PC  a écrit :
>>
>> Noter que le serveur ici acceptait en effet la connexion par mot de
>> passe, ce qui est une mauvaise idée, mais, j'en était au début de sa
>> configuration. Entre temps, j'ai interdit la connexion par mot de passe.
>>
>> J'étais donc justement entrain de reprendre mes différents tutoriels
>> pour les éprouver lors d'une installation standard.
>> J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison.
>>
>> Cette installation m'a permis d'être confronté à cette problématique de
>> droits, pour mes propres clés, et, de ce bogue ( manque d'informations )
>> pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits.
>
> Bonjour,
> il faut tenir compte ici du fait que celui qui se connecte n'est pas 
> forcément un utilisateur légitime à qui on a envie de fournir des 
> informations sur la configuration du serveur cible.
> Le message concernant la clef est plus à sa place dans les logs du serveur.
>
> Cordialement
>
> Éric Dégenètais



Re: Don't disable recoomends by default

2019-07-12 Thread Reco
On Fri, Jul 12, 2019 at 09:13:29AM -0300, Jonas Smedegaard wrote:
> Quoting Reco (2019-07-12 09:01:33)
> > > > Disabling installing Recommends by default also helps a great deal 
> > > > with all those dependencies you don't want.
> > > 
> > > Above may break your system in confusing to debug ways,
> > 
> > Rly? Recommends are called that for a reason.
> 
> Yes, and the reason is well defined: Packages requires in "all but 
> unusual installations." - quoted from Debian Policy §7.2.

This only shows us that one can prove anything by using selective
quoting. Full quote, btw is:

This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together
with this one in all but unusual installations.


Therefore Debian Policy explicitly says that Recommends are not
required.


> > If Recommend is actually needed for the correct functioning of the
> > package - it's a bug in a package.
> 
> Wrong.  If a package is possibly to use for any purpose at all, even if 
> exotic and unusual, then it makes sense to recommend instead of depend 
> on a package.

Let's take everyone's favorite package, systemd.
It's Recommends as of stretch are libpam-systemd and dbus.
Both are not required for the OS to boot and systemd to function. Also,
they are optional for the users' login.
Moreover, there's no need for both libpam-systemd and dbus to be
installed on a typical server (be it file server, print server, db
server or a web server).
Of course, if server environment is "exotic and unusual" to someone -
that's an entirely different matter.


> > Recommends are useful sometime, and it's a useful default to install 
> > them. But it comes with the cost and the cost is a dependency bloat.
> 
> Wrong.  Suggests are for packages useful only "sometimes", recommends 
> are for pacakges needed in "all but unusual installations."

See above.

Reco



Re: Don't disable recoomends by default

2019-07-12 Thread Stephan Seitz

On Fr, Jul 12, 2019 at 09:13:29 -0300, Jonas Smedegaard wrote:

Wrong.  Suggests are for packages useful only "sometimes", recommends
are for pacakges needed in "all but unusual installations."


From my experience this is wrong.

With recommends my d10 update would have systemd as init instead of 
sysvinit. And I would have got (for example) the package debsecan which 
I don’t need.


So it is better to disable recommends and look at the recommended 
packages.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: PGP signature


Re: Preguntas

2019-07-12 Thread Debian

El 12/7/19 a las 07:56, Paynalton escribió:



El vie., 12 de julio de 2019 2:26 a. m., Galvatorix Torixgalva 
mailto:galvatorix2...@gmail.com>> escribió:


Hola,

nuevo en linux?, pues tranquilo que todos hemos pasado por ahi ;)

a ver, lo que comentas...

"el proceso lo realice desde una maquina virtual primero"
buena idea, sobretodo cuando estas comenzando

"es algo difícil pero no imposible de que afecte directamente a la pc"
quedate tranquilo que VirtualBox y Linux son viejos conocidos y lo
que tu estas haciendo (instalar Debian en VirtualBox) es bastante
habitual, el riesgo de que le pase algo a tu ordenador por eso es
muy bajo

"casi finalizando me sale unas letras extrañas"
te refieres a lo que sale en la imagen que has enviado?. Eso podria
ser algun error extraño (y sin importancia real) del instalador.
Podrias revisar tambien la configuracion de la tarjeta de video en
virtualbox, por si acaso.


Agregando algo a lo que te comentan, este error puede ocurrir cuando el 
virtualbox sobre windows no tiene correctamente configurada la 
codificación de carácteres en el visor de terminal, usualmente por poner 
"windows" o algo más como sistema operativo al crear la máquina virtual. 
Esto sólo te afectará en el modo consola, tanto el instalador gráfico 
como el escritorio no deberían verse afectados. Al intalar "físicamente" 
tampoco deberías tener ese problema.



"¿Es normal que aparezca esto en la instalación?"
no, pero tampoco le des demasiada importancia si no se repite y no
sucede nada mas.

"¿No se dañara mi pc cuando lo instale directamente?"
Si te refieres a que si instalar debian puede causar una averia
fisica en tu ordenador, la respuesta es negativa. Linux en general,
y Debian en particular, es compatible con la inmensa mayoria del
hardware que se usa actualmente, y bastante del hardware
relativamente antiguo. En el manual de Debian (disponible en la web
de Debian) tienes los requisitos de hardware.

Si quieres quedarte mas tranquilo podrias probar algun LiveCD como
por ejemplo knoppix. Knoppix es una forma de usar Linux en tu
ordenador SIN instalarlo. Se ejecuta todo en memoria RAM y (insisto)
no se instala nada en el disco duro. Podrias usarlo para ver si todo
tu hardware (procesador, placa base, memoria ram, tarjeta de video,
etc) es compatible con linux. Knoppix basicamente te lo da todo
(casi) hecho, solamente te preguntara algunas cosas basicas.

"Ya que hace tiempo supe que habían problemas con Ubuntu y una
versión que había sido publicada estaba quemando la BIOS  de la pc"
seria importante saber exactamente que ha pasado ahi, con detalles.
especialmente todo lo relacionado con ese ordenador y esa bios

Un detalle final sobre tu ordenador. Me ha llamado la atencion la
poca memoria ram que tiene (512 Megas). Ten eso en cuenta tanto
durante la instalacion como cuando uses linux.

Un saludo




Con esa cantidad de RAM, te sugiero que instales damn small linux.
Una arquitectura de 32 bits con apenas 512 en RAM, es muy difícil que 
funcione con algo superior a "Lenny" (Debian 5).


Lo máximo que he podido forzar en un sistema de 32 bit, con 1GB RAM, fue 
Weezy (Debian 7) y que funcione modestamente bien.


Subiéndole de 1 a 2GB de RAM, entró un Jessie (Debian 8), con un 
escritorio mínimo en LXDE.


Estimo que Systemd es uno de los responsables del problema, además del 
crecimiento que ha tenido el kernel en sí mismo.



JAP



Don't disable recoomends by default

2019-07-12 Thread Jonas Smedegaard
Quoting Reco (2019-07-12 09:01:33)
> > > Disabling installing Recommends by default also helps a great deal 
> > > with all those dependencies you don't want.
> > 
> > Above may break your system in confusing to debug ways,
> 
> Rly? Recommends are called that for a reason.

Yes, and the reason is well defined: Packages requires in "all but 
unusual installations." - quoted from Debian Policy §7.2.


> If Recommend is actually needed for the correct functioning of the
> package - it's a bug in a package.

Wrong.  If a package is possibly to use for any purpose at all, even if 
exotic and unusual, then it makes sense to recommend instead of depend 
on a package.


> Recommends are useful sometime, and it's a useful default to install 
> them. But it comes with the cost and the cost is a dependency bloat.

Wrong.  Suggests are for packages useful only "sometimes", recommends 
are for pacakges needed in "all but unusual installations."


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Re: Repair Grumb

2019-07-12 Thread songbird
Stephen P. Molnar wrote:
> I have Stretch installed  on sda1 and Buster installed on sdd1 on my 
> 64bit Linux platform.
>
> Unfortunately, grub on sdd1 became corrupted and the boot process fails 
> after Buster is selected. Fortunately, the Stretch grub still boots the 
> system.  Also, I can access the Buster install on sdd1 without any problems
>
> At this point I have downloaded  the Boot Repair dist from Soourceforge 
> -boot-repair-disk-64bit.iso and burned it to a DVD. The repair disk 
> boots without any problems.  However, I am a bit hesitant to use the 
> repair tool.  If I select sdd1 as the location for the repair in the 
> advanced tab is there any danger of corrupting the Stretch grub on sda1?

  i'm not familiar with this tool and don't know what
it does.

  is there some reason you cannot use the original
Buster install media which has a rescue menu/option?

  adding someone else's idea of what the device should
have on it aside from the Debian version sounds like
a complicating factor which is usually not a good idea
when trying to troubleshoot.


> Of course, the safest thing would be to just reinstall Buster on sdd1. I 
> hav already backed up the files.

  i think so.  i would unplug sda first (after turning
off the machine) to make sure you don't change it.

  once you have the system booting from sdd then you
can turn the machine off again, plug sda back in and
boot it and make sure that still works and run your
update-grub from there to pick up buster.


> Comments and guidance will be much appreciated.

  i see in your other note that you say you have no
clue as to what happened.

  to me this really indicates that you are not suited
for the things you are doing.  in other words, if you
want to get better at this sort of thing you need to
take notes or record your terminal sessions because
none of us can tell what you're doing either.


  songbird



Re: useless languages

2019-07-12 Thread Reco
Hi.

On Fri, Jul 12, 2019 at 08:37:09AM -0300, Jonas Smedegaard wrote:
> > apt install chromium task-marathi-desktop- task-nepali-desktop- ...-
> 
> Above would help if chromium was recommending task-* packages which it 
> doesn't on Debian, so for Debian systems I doubt that would help here.

Try it sometime. If it's installed - it will be uninstalled.
If it's trying to install - it won't. Applies to the task* packages like
it applies to anything else.


> > Disabling installing Recommends by default also helps a great deal with
> > all those dependencies you don't want.
> 
> Above may break your system in confusing to debug ways,

Rly? Recommends are called that for a reason.
If Recommend is actually needed for the correct functioning of the
package - it's a bug in a package.
Recommends are useful sometime, and it's a useful default to install
them. But it comes with the cost and the cost is a dependency bloat.

Not installing the Depends - that's a creative way to break a system
indeed. But even this has its uses.


> so if you ever do that then make sure to clearly mention it when you
> later report bugs!

Try running reportbug in this case. It tells this particular setting
every time by showing which Recommends are installed and which are not.


In short, Debian's (and derivatives') package management and bug
reporting is more flexible that you seem to think it is.

Reco



Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

2019-07-12 Thread Eric Degenetais
Le ven. 12 juil. 2019 13:04, G2PC  a écrit :

> Noter que le serveur ici acceptait en effet la connexion par mot de
> passe, ce qui est une mauvaise idée, mais, j'en était au début de sa
> configuration. Entre temps, j'ai interdit la connexion par mot de passe.
>
> J'étais donc justement entrain de reprendre mes différents tutoriels
> pour les éprouver lors d'une installation standard.
> J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison.
>
> Cette installation m'a permis d'être confronté à cette problématique de
> droits, pour mes propres clés, et, de ce bogue ( manque d'informations )
> pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits.
>
Bonjour,
il faut tenir compte ici du fait que celui qui se connecte n'est pas
forcément un utilisateur légitime à qui on a envie de fournir des
informations sur la configuration du serveur cible.
Le message concernant la clef est plus à sa place dans les logs du serveur.

Cordialement

Éric Dégenètais


Re: useless languages

2019-07-12 Thread Jonas Smedegaard
Hi Pierre,

Quoting Reco (2019-07-12 08:09:03)
> On Fri, Jul 12, 2019 at 01:03:33PM +0200, Pierre Frenkiel wrote:
> > when installing some packages (chromiun for example), I get a lot of 
> > useless languages (task-marathi-desktop task-nepali-desktop ...) Is 
> > there a way to get rid of them?

On Debian or somethins else (perhaps something derived from Debian, like 
Raspbian or Armbian or Ubuntu or Kubuntu or...)?

And which exact command causes chromium to pull in those task-* packages 
on your sysstem?

I ask because I cannot recognize that Debian systems (neither stable 
Buster or oldstable Stretch) has chromium recommend or even suggest any 
task-* packages.  So I suspect that you have something custom/derived 
causing this odd behaviour.


> apt install chromium task-marathi-desktop- task-nepali-desktop- ...-

Above would help if chromium was recommending task-* packages which it 
doesn't on Debian, so for Debian systems I doubt that would help here.


> Disabling installing Recommends by default also helps a great deal with
> all those dependencies you don't want.

Above may break your system in confusing to debug ways, so if you ever 
do that then make sure to clearly mention it when you later report bugs!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Re: Flatpak or repository apps

2019-07-12 Thread Reco
On Fri, Jul 12, 2019 at 09:33:44AM +0300, Georgios wrote:
> Hi there!
> 
> Based on security and stability i was wondering what is more preferable?
> 
> Installing apps through flatpak or through debian repositories?

I trust Debian at packaging software, correcting obvious software
defects in the process, and supporting the unchanged behaviour of the
software during the lifecycle of the stable release while providing the
bugfixes.
For the typical software developer (especially those who write "apps",
not "programs"), maintaining a stable version of their software is a
burden, and a "security" is an unfamiliar concept.


> Repositories:
> 
> -I was thinking that in repositories you have old software that gets
> bugs fixes. But what about old software that it isnt supported?

By the upstream, you mean? If it's a security problem it will be get
fixed or the package is excluded from the archive.

> Are fixes backported etc?

Of course, if it's feasible.
If it's not - software version gets bumped (browsers, samba, wireshark
to name a few examples).

> How fast?

Faster if the maintainer gets help. From the users of the software, for
instance.

> -Doesnt offer easy sandboxing like flatpak

Which is only need for the untrusted software in the first place.
Crucial for the task flatpak was designed for (delivering desktop "apps"
taken from random places at Internet), but is something one can easily
avoid by using a trusted software in the first place (i.e. Debian main
archive).

> -Apparmor can restrict applications

Yup. And it's a useful compromise between security and usability.
The main problem of apparmor is that it uses targeted approach (every
policy is linked to executable) instead of more correct labeled approach
like MLS SELinux policy does.

> Flatpak:
> 
> -sandboxing

See above.

> -Propably bug fixes are faster if the developer support flatpak distribution

Alongside with behaviour changes, possible incompatibility to previous
versions, and of course - fresh new bugs.

> -No Apparmor.

True. But if it bothers you consider using SELinux, which does offer
something in this regard. The problem is - you choose wrong distribution
if you need SELinux (it's barebone basic in Debian).

> -are the latest applications stable enough?

LOL. Why do you think they invented version stabilization in the first
place? If you like to live on a bleeding edge you have to bleed sooner
or later.

Reco



Re: Repair Grumb (grub)

2019-07-12 Thread Brian
On Fri 12 Jul 2019 at 06:08:13 -0400, Stephen P. Molnar wrote:

> Plese see responses to questions. .  .  .  .
> 
> On 07/11/2019 11:16 PM, David wrote:
> > On Fri, 12 Jul 2019 at 05:09, Stephen P. Molnar  
> > wrote:
> > > I have Stretch installed  on sda1 and Buster installed on sdd1 on my
> > > 64bit Linux platform.
> > > 
> > > Unfortunately, grub on sdd1 became corrupted and the boot process fails
> > > after Buster is selected.
> > Everyone reading this wonders:
> > 1) why are you hiding the most important facts in your question?
> > 2) what exact symptoms cause you to conclude that "grub on sdd1 became
> >  corrupted"?
> After allowing choice of Buster the boot hung with a '>' prompt.

At the prompt type 'ls' and post the output.

-- 
Brian.



Re: Mise à jour jessie --> buster

2019-07-12 Thread Quentin Lejard
Bonjour,

Le 12/07/2019 à 12:33, hamster a écrit :

> Il n'est pas du tout recommandé de sauter une version dans les mise a
> jour de distrib.
>
> De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les suivant
> dans le fil, sur un poste de travail je préfère refaire l'install plutot
> que mettre a jour, alors a fortiori si tu a une version de retard.
>
Je confirme, tu seras à l'abri des mauvaises surprises.
Et puis tu repars sur quelques choses de propre.

-- Quentin Lejard (valde) - wiki.debian.org/QuentinLejard ⢀⣴⠾⠻⢶⣦⠀ Blog :
blog.valde.fr ⣾⠁⢠⠒⠀⣿⡁ Git : framagit.org/valde ⢿⡄⠘⠷⠚⠋ twitter :
@__valde__ , @DebianFrance ⠈⠳⣄ mastodon : framapiaf/@valde ,
@DebianFr GPG : 16FF-0108-6751-7910-D6B3-4691-DFCD-FB55-F54D-C2E2



Re: useless languages

2019-07-12 Thread Reco
Hi.

On Fri, Jul 12, 2019 at 01:03:33PM +0200, Pierre Frenkiel wrote:
> hi,
> when installing some packages (chromiun for example), I get a lot of
> useless languages (task-marathi-desktop task-nepali-desktop ...)
> Is there a way to get rid of them?

apt install chromium task-marathi-desktop- task-nepali-desktop- ...-

Disabling installing Recommends by default also helps a great deal with
all those dependencies you don't want.

Reco



useless languages

2019-07-12 Thread Pierre Frenkiel

hi,
when installing some packages (chromiun for example), I get a lot of
useless languages (task-marathi-desktop task-nepali-desktop ...)
Is there a way to get rid of them?

best regards,
--
Pierre Frenkiel



Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

2019-07-12 Thread G2PC
Noter que le serveur ici acceptait en effet la connexion par mot de
passe, ce qui est une mauvaise idée, mais, j'en était au début de sa
configuration. Entre temps, j'ai interdit la connexion par mot de passe.

J'étais donc justement entrain de reprendre mes différents tutoriels
pour les éprouver lors d'une installation standard.
J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison.

Cette installation m'a permis d'être confronté à cette problématique de
droits, pour mes propres clés, et, de ce bogue ( manque d'informations )
pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits.



Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

2019-07-12 Thread G2PC


>> sshfs -o allow_other,
>> IdentityFile=/home/$USERLOCAL/.ssh/$SERVEUR/id_rsa_private
>> $USERSERVEUR@$SERVEUR:/home/$USERSERVEUR/$FOLDER /home/$USERLOCAL/$FOLDER
>> Si l'utilisateur qui se connecte est l'utilisateur root de la machine
>> locale, la phrase secrète est requise lors du montage de dossiers
>> partagés.
> Tu es sûr que c'est la phrase secrète de la clé privée qui est demandée, et
> qu'elle est ensuite utilisée ? Ça m'étonne, ça voudrait dire que ssh
> tolèrerait une clé privée en 644 si c'est root qui l'utilise, ça ce serait
> un bug (de ssh), j'en doute un peu, je pense qu'il demande aussi le pass
> de $USERSERVEUR@$SERVEUR si c'est root qui lance la commande (et que la
> clé privée est en 644, et que $SERVEUR accepte les connexions par mot de
> passe, ce qui est par ailleurs une mauvaise idée).
> Je comprends ton point de vue, à partir du moment où tu lui précises une clé
> à utiliser il devrait le faire ou s'arrêter avec le bon message d'erreur,
> mais c'est visiblement pas l'option choisie par les développeurs de sshfs
> (je sais pas si c'est un choix délibéré ou un oubli, tu as bien fait de
> poser la question).


Merci de ta réponse ! Tu me met un doute de plus, et, à juste raison !
Je partais du principe que ce problème de message d'erreur qui indique
que les droits ne sont pas corrects pour la clé privée lors de la
connexion SSH, ne concernait que le simple utilisateur.
J'avais donc identifié cette absence de message d'erreur, pour un simple
utilisateur voulant établir une connexion SSHFS ce qui entraîne une
demande de mot de passe car la clé n'est pas considérée, au lieu de
demander la passphrase.

Tu me dis, " Ça m'étonne, ça voudrait dire que ssh tolèrerait une clé
privée en 644 si c'est root qui l'utilise, ça ce serait un bug (de ssh)  "

Effectivement ! Pour SSH, et, SSHFS, l'utilisateur root devrait la aussi
transmettre une alerte, une information, pour rappeler que la clé privée
ne possède pas les bons droits.
Je pense que c'est bien un bogue de SSH et SSHFS, car, comme je te le
dis, j'arrive bien à me connecter en root, sans message d'erreur, avec
une clé privée en 664.

Donc, j'ai bien identifié l'absence d'un message d'information sur
SSHFS, et, nous avons identifié l'absence de message d'information lors
de l'utilisation de root, pour une connexion SSH ou SSHFS lorsque la clé
privée a les droits 664.

J'ai remonté la question ici sur Debian, car, il me semblait bien que ça
pouvait intéresser quelques correcteurs.
Ce problème a été identifié sur une Mint Tessa 19.2 mais, je suppose que
pour SSHFS, ça ne change rien. Jai ouvert la question sur le projet
Github de SSHFS, mais, ce n'est pas dit que quelqu'un s'en charge.

Si quelqu'un peut remonter cette information, pour vérifier ce problème
pour SSH ?

https://github.com/libfuse/sshfs/issues/180




Re: Preguntas

2019-07-12 Thread Paynalton
El vie., 12 de julio de 2019 2:26 a. m., Galvatorix Torixgalva <
galvatorix2...@gmail.com> escribió:

> Hola,
>
> nuevo en linux?, pues tranquilo que todos hemos pasado por ahi ;)
>
> a ver, lo que comentas...
>
> "el proceso lo realice desde una maquina virtual primero"
> buena idea, sobretodo cuando estas comenzando
>
> "es algo difícil pero no imposible de que afecte directamente a la pc"
> quedate tranquilo que VirtualBox y Linux son viejos conocidos y lo que tu
> estas haciendo (instalar Debian en VirtualBox) es bastante habitual, el
> riesgo de que le pase algo a tu ordenador por eso es muy bajo
>
> "casi finalizando me sale unas letras extrañas"
> te refieres a lo que sale en la imagen que has enviado?. Eso podria ser
> algun error extraño (y sin importancia real) del instalador. Podrias
> revisar tambien la configuracion de la tarjeta de video en virtualbox, por
> si acaso.
>

Agregando algo a lo que te comentan, este error puede ocurrir cuando el
virtualbox sobre windows no tiene correctamente configurada la codificación
de carácteres en el visor de terminal, usualmente por poner "windows" o
algo más como sistema operativo al crear la máquina virtual. Esto sólo te
afectará en el modo consola, tanto el instalador gráfico como el escritorio
no deberían verse afectados. Al intalar "físicamente" tampoco deberías
tener ese problema.


> "¿Es normal que aparezca esto en la instalación?"
> no, pero tampoco le des demasiada importancia si no se repite y no sucede
> nada mas.
>
> "¿No se dañara mi pc cuando lo instale directamente?"
> Si te refieres a que si instalar debian puede causar una averia fisica en
> tu ordenador, la respuesta es negativa. Linux en general, y Debian en
> particular, es compatible con la inmensa mayoria del hardware que se usa
> actualmente, y bastante del hardware relativamente antiguo. En el manual de
> Debian (disponible en la web de Debian) tienes los requisitos de hardware.
>
> Si quieres quedarte mas tranquilo podrias probar algun LiveCD como por
> ejemplo knoppix. Knoppix es una forma de usar Linux en tu ordenador SIN
> instalarlo. Se ejecuta todo en memoria RAM y (insisto) no se instala nada
> en el disco duro. Podrias usarlo para ver si todo tu hardware (procesador,
> placa base, memoria ram, tarjeta de video, etc) es compatible con linux.
> Knoppix basicamente te lo da todo (casi) hecho, solamente te preguntara
> algunas cosas basicas.
>
> "Ya que hace tiempo supe que habían problemas con Ubuntu y una versión que
> había sido publicada estaba quemando la BIOS  de la pc"
> seria importante saber exactamente que ha pasado ahi, con detalles.
> especialmente todo lo relacionado con ese ordenador y esa bios
>
> Un detalle final sobre tu ordenador. Me ha llamado la atencion la poca
> memoria ram que tiene (512 Megas). Ten eso en cuenta tanto durante la
> instalacion como cuando uses linux.
>
> Un saludo
>
>
>


Re: Mise à jour jessie --> buster

2019-07-12 Thread hamster
Le 12/07/2019 à 11:56, Francois Meyer a écrit :
> Bonjour à tous
>
> J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il mieux
> passer par Stretch ou sauter directement à Buster d'après vous ?

Il n'est pas du tout recommandé de sauter une version dans les mise a
jour de distrib.

De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les suivant
dans le fil, sur un poste de travail je préfère refaire l'install plutot
que mettre a jour, alors a fortiori si tu a une version de retard.



Mise à jour jessie --> buster

2019-07-12 Thread Francois Meyer

Bonjour à tous

J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il mieux 
passer par Stretch ou sauter directement à Buster d'après vous ? 
Autrement dit, est-ce que je mets "stretch" ou "stable" à la place de 
"jessie" dans mon source.list ?


Bonne journée

François



Re: Repair Grumb (grub)

2019-07-12 Thread Stephen P. Molnar

Plese see responses to questions. .  .  .  .

On 07/11/2019 11:16 PM, David wrote:

On Fri, 12 Jul 2019 at 05:09, Stephen P. Molnar  wrote:

I have Stretch installed  on sda1 and Buster installed on sdd1 on my
64bit Linux platform.

Unfortunately, grub on sdd1 became corrupted and the boot process fails
after Buster is selected.

Everyone reading this wonders:
1) why are you hiding the most important facts in your question?
2) what exact symptoms cause you to conclude that "grub on sdd1 became
 corrupted"?

After allowing choice of Buster the boot hung with a '>' prompt.

3) did it ever work properly after installation, ie are we discussing a borked
 installation attempt, or did it work for a while and then "became"
non-working?
Worked fine after installation, until it no longer did.  I don't have 
the faintest idea as to why.

4) what is the method that you use to change from attempting to boot sda1,
 or attempting to boot sdd1?
F8 during post brings up a window listing drives and allowing choice of 
either sda or sdd. Ir I choise sdd the system hangs, if I chaise sda 
Stretch boots.

5) at what point in that method does "boot process fails" occur, and

After the choice for the process to continue to Buster.

 what are its exact symptoms?
6) is EFI involved?

No


Your chances of receiving useful assistance are always improved by
providing a detailed description of *the failure*. Without them, readers
can only guess at what the problem might be, and readers with expertise
are unlikely to respond because they have more interesting things to
do than try to guess what someone is talking about.

It is possible that the only "repair tool" you need is grub itself.
You might just need to run 'grub-install' and specify sdd (not sdd1)
as the target device (but I'm not certain, due to the lack of facts).
See here:
https://www.gnu.org/software/grub/manual/grub/grub.html#Invoking-grub_002dinstall
Please be aware that if this command is misused it could make
your machine unbootable. But if used correctly it should be fine.


Comments and guidance will be much appreciated.
Thanks in advance.

I did my best. Hope it helps. If you provide the additional details
requested, we might be able to offer better help. Good luck :)




--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
http://www.Molecular-Modeling.net   Multivariate and stochastic
614.312.7528 (c)
Skype:  smolnar1



Re: (deb-cat) Alerta amb gnome-disk-utility

2019-07-12 Thread Narcis Garcia
__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 11/7/19 a les 20:01, Robert Marsellés ha escrit:
> 
> 
> El 10/7/19 a les 20:11, Narcis Garcia ha escrit:
>> __

> Molt important (importantíssim) per qui utilitza volums xifrats:
> https://bugs.debian.org/928893

 M'hi he subscrit, mil gràcies!

>>>
>>> Únicament volia dir que si és fa el que s'aconsella abans d'instal·lar o
>>> actualitzar (RTFM), hi ha tots aquests problemes de que esteu parlant a
>>> les notes de l'alliberament de la distribució (Cap. 5, Issues to be
>>> aware of for Buster) [1, 2].
>>>
>>> [1] https://www.debian.org/releases/buster/amd64/release-notes/index.en.html
>>>
>>> [2] https://www.debian.org/releases/buster/amd64/release-notes/index.es.html
>>>
>>
>> Estic instal·lant un ordinador amb xifrat, i m'agradaria saber si algú
>> coneix una aplicació d'escriptori alternativa que a l'usuari inexpert li
>> pugui servir per a fer el canvi de contrasenya LUKS.
>>
> 
> Jo sóc un usuari inexpert també. Jo uso l'eina per defecte (cryptsetup)
> via terminal + root (o sudo). Després de llegir-se el "man cryptsetup",
> no em sembla tan complicat. Això si, no és una eina que utilitzi
> habitualment (usuari inexpert) i sempre l'haig de rellegir quan vull fer
> o saber "algo".
> 
> En el cas particular que dius, el més senzill seria:
> 
> # cryptsetup luksChangeKey [device]
> 
> Si no se li dóna un fitxer amb la nova clau, la demana de forma
> interactiva. Per saber el valor de [device] (jo l'oblido sempre o és un
> UUID, ...), jo utilitzo abans l'ordre:
> 
> # cryptsetup status [name]
> 
> per que em doni la informació, on [name] és el nom que li vaig donar a
> la partició que tinc encriptada. Com que li vaig donar jo, la recordo.
> Si no fos el cas, [name] és el primer camp de l'arxiu /etc/crypttab (jo
> únicament tinc 1 partició encriptada. Si vosaltres en teniu més d'una,
> cada línia correspon a una partició encriptada del vostre sistema).
> 
> Espero que serveixi. Jo ho trobo força simple. El més complicat per mi
> és recordar el nom del "device" amb el que vull treballar i això també
> li has de dir a l'eina d'escriptori si no, no farà rés.

Jo també ho havia fet per aquesta via, però per a les meves coses.
La majoria d'usuaris per a qui faig instal·lacions de Debian entenen el
què significa que una memòria USB estigui xifrada, però no arriben tant
lluny com per a saber el què és una partició o conèixer com es llegeix
un fitxer com /etc/crypttab (on no apareixen els volums removibles).

Per la majoria dels mortals (subjectes a les normes i la ètica de
protecció de dades), ja és un esforç encertar amb el controlador
correcte quan configuren una impressora via GUI.

Gràcies.



Re: openvpn privatvpn

2019-07-12 Thread Daniel Huhardeaux

Le 12/07/2019 à 06:02, Daniel Caillibaud a écrit :

Le 11/07/19 à 18h50, MERLIN Philippe  a
écrit :

Une analyse par Wireshark indique seulement que les DNS ne
fonctionnent pas.


Je ne connais pas l'origine du pb, mais tu peux installer un resolver
local, c'est très léger et ça rend pas mal de services (ça évite les dns
parfois menteurs des FAI, mais surtout ça marche toujours alors que
suivant les FAI la résolution dns laisse parfois à désirer, et en prime tu
va gagner un poil en perfs).

apt install unbound

et dans /etc/resolv.conf mettre
nameserver 127.0.0.1

(ou bien l'indiquer dans le network manager, ou ton système de gestion de
la résolution locale)


Attention si c'est systemd-resolved qui gère le DNS la valeur 127.0.0.1 
est à mettre dans /etc/systemd/resolved cle [Resolve] => DNS


--
Daniel



Re: [SOLVED] tailf vs buster

2019-07-12 Thread tomas
On Fri, Jul 12, 2019 at 11:35:20AM +0300, Reco wrote:
>   Hi.
> 
> On Fri, Jul 12, 2019 at 09:55:03AM +0200, to...@tuxteam.de wrote:
> > On Thu, Jul 11, 2019 at 06:55:43PM +0300, Reco wrote:
> > 
> > [...]
> > 
> > > Figures. RedHat deserves whatever IBM will do to them.
> > 
> > You seem to be unaware of what RedHat has done for all of us.
> 
> On the contrary. I'm perfectly aware of this.
> I don't dispute that RedHat did a lot of good things - good chunks of
> the libc, gcc and a kernel itself is wrote by them.

Good, thanks then.

> On the other side though we have some really controversial things like
> SecureBoot support, Wayland, GTK3, xfs, and s*d.

Right. And lots of food for thought on what free software is, what it
means for each of us, whether it has something to do with society,
whether it's compatible with big corps, yadda yadda.

Lots of interesting work ahead :-)

Cheers
-- tomás


signature.asc
Description: Digital signature


Re: Minimial Live Image

2019-07-12 Thread Rick Thomas



> On Jul 11, 2019, at 11:06 AM, J.Arun Mani  wrote:
> 
> Hi
> 
> Im planning to install Debian in my (already Linux Mint powered) laptop. But 
> the ISO size is huge (~2.7 GB), something beyond my per-day bandwidth limit 
> of 1.5 GB (actually 2 GB, but .5 GB is spent in other personal things). And I 
> also found that Debian ships with a large pack of softwares and does not have 
> (official) support for propertiary drivers.
> 
> So what I want is a live bootable minimial ISO with a DE (a basic one is 
> enough if DEs can be changed easily later) and a basic set of packages with 
> support for propertiary drivers (is there anyother way to get it if Debian 
> doesn't provide it officially ?).
> 
> My dear friends, help me, where can I find such ISOs? (No Netinst or Network 
> boot, because of my Internet speed and other issues)
> 
> Nice day :)
> J Arun Mani

Hi!

I found this [1] 1.3GB image.  (“standard” = no DE, just text console.  But you 
can add any DE you want later with “sudo tasksel”.)  That’s just barely under 
your stated daily bandwidth allowance of 1.5GB.  Everything else (the images 
that include a DE GUI) is hovering around 2.5GB.

You can also get it from bittorrent at [2].  Bittorrent is recommended if you 
have a choice, because it minimizes the load on the debian.org servers.

Hope it helps!

Rick

[1] 
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/10.0.0-live+nonfree/amd64/iso-hybrid/debian-live-10.0.0-amd64-standard+nonfree.iso

[2] 
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/10.0.0-live+nonfree/amd64/bt-hybrid/debian-live-10.0.0-amd64-standard+nonfree.iso.torrent


Re: chromebook

2019-07-12 Thread tomas
On Fri, Jul 12, 2019 at 07:57:33AM -, Curt wrote:
> On 2019-07-12,   wrote:
> >
> >
> > I have the impression you're being blindsided by ideology there. To me,
> 
> C’est l’hôpital qui se moque de la charité.

:-)

But still, *my* ideology is right and *yours* is wrong ;-P

Cheers
-- t


signature.asc
Description: Digital signature


Re: [SOLVED] tailf vs buster

2019-07-12 Thread Reco
Hi.

On Fri, Jul 12, 2019 at 09:55:03AM +0200, to...@tuxteam.de wrote:
> On Thu, Jul 11, 2019 at 06:55:43PM +0300, Reco wrote:
> 
> [...]
> 
> > Figures. RedHat deserves whatever IBM will do to them.
> 
> You seem to be unaware of what RedHat has done for all of us.

On the contrary. I'm perfectly aware of this.
I don't dispute that RedHat did a lot of good things - good chunks of
the libc, gcc and a kernel itself is wrote by them.
On the other side though we have some really controversial things like
SecureBoot support, Wayland, GTK3, xfs, and s*d.

Reco



Re: Onbruikbaar installeerscherm

2019-07-12 Thread Jaap van Wingerde

> Geert Stappers  schreef op July 7, 2019 8:54:42 PM UTC:
>> 
>>> On Sun, Jul 07, 2019 at 10:15:08PM +0200, Jaap van Wingerde wrote:
>>> MedeDebianen,
>>> 
>>> Ik probeer Debian te installeren op mijn nieuwe zuinige moederbordje
>>> van Fujitsu. Ik heb met dd mini.iso op een USB-stick gezet. Als ik het
>>> systeem met deze stick laat opstarten, en voor "install" kies krijg ik
>>> tot mijn stomme verbazing een beeldscherm met bovenin 10 mini
>>> installeerschermpjes (, jaja
>>> oud certificaat). Dit lijken gewone installeerschermen, maar de tekst is
>>> te klein om te lezen. Wat heb ik nu aan mijn fiets hangen?
>> 
>> Mijn eerste inschatting was  kernel die een vreemde video mode aanneemt.
>> 
>> Na het zien van het plaatje zou ik eerst een andere monitor proberen.
Er bleek niets aan de hand met de monitor. Om onduidelijke redenen verdween het 
probleem nadat ik in het bios ‘above 4g encoding’ op ‘disabled’ zette.

Daarna bleek er geen driver voor de Intel I219-LM netwerk in de installer te 
zitten. Een rondslingerend wifi-stikkie bracht helaas geen verbinding tot 
stand. Toen heb ik mijn Android-telefoon op usb-theterering gezet en op de 
computer aangesloten. De installer herkende deze verbinding en ging aan het 
werk.

Re: Where'd lsb-compat go?

2019-07-12 Thread Tixy
On Thu, 2019-07-11 at 13:48 -0500, Kent West wrote:
[..]
> Today, 
> when I go to install "lsb-compat" on the other's, I find it's no longer 
> available in Buster. Has it been deprecated?

Seems so, Googling for "debian lsb-compat buster" shows...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873090

[...]

>  For completeness:
> 
> root@lib-pac-04:~# cat /etc/apt/sources.list
> #
> 
> 
> deb http://ftp.us.debian.org/debian/ stable main contrib non-free
> deb-src http://ftp.us.debian.org/debian/ stable main contrib non-free
[...]

Well, the 'stable' release changed from 'stretch' to 'buster' a few
days ago, so your systems are possibly now going to be a mix of those
two releases, probably not what you wanted. Really, you want the
codenames of the release you want to run in sources.list, not 'stable'.
Then you can explicitely upgrade to a new release at a time of your
choosing, taking into consideration what the release notes say and
leasons leaned from upgrading one of your systems first.

-- 
Tixy



Re: Upgrade to Buster and perl Device::SerialPort

2019-07-12 Thread tomas
On Thu, Jul 11, 2019 at 05:39:28PM -0700, David Christensen wrote:
> On 7/11/19 1:29 AM, to...@tuxteam.de wrote:
> >On Wed, Jul 10, 2019 at 07:53:23PM -0700, David Christensen wrote:
> >>On 7/10/19 10:39 AM, Martin McCormick wrote:
> >>>David Christensen  writes:
> >
> >[...]
> >
> >Good points all around.
> >
> >>I would check for existence of the device (-e) and die if not present.
> >
> >Perhaps even check whether the device is character special (-c): ISTR
> >the code tries to do some stty stuff which will fail otherwise.
> 
> I have always tried to do thorough error checking.  In the past, I
> have taken argument and/or state checking to the extreme.

We're in violent agreement here: my "perhaps" was meant seriously (as
"I don't know whether I'd do it: think about it" and not as a polite
way of saying "you definitely gotta do this").

Cheers
-- t


signature.asc
Description: Digital signature


Re: chromebook

2019-07-12 Thread Curt
On 2019-07-12,   wrote:
>
>
> I have the impression you're being blindsided by ideology there. To me,

C’est l’hôpital qui se moque de la charité.

-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan



Re: [SOLVED] tailf vs buster

2019-07-12 Thread tomas
On Thu, Jul 11, 2019 at 06:55:43PM +0300, Reco wrote:

[...]

> Figures. RedHat deserves whatever IBM will do to them.

You seem to be unaware of what RedHat has done for all of us.

Cheers
-- tomás


signature.asc
Description: Digital signature


Re: chromebook

2019-07-12 Thread tomas
On Thu, Jul 11, 2019 at 11:34:01AM -0500, John Hasler wrote:
> tomas writes:
> > I think bigcorps love that, because they hate the decentralized nature
> > of mail.
> 
> I don't think they care (except that they don't want one of their
> competitors in control). 

Oh, they do. You can't easily monetize mail (the interfaces are standard,
for a consumer it's easy to change providers), whereas with whichever
"platform" (Facebook, LinkedIn, Slack, Google+, younameit) the audience
is captive: changing provider means giving up on your network.

>  Government hates it, of course.  It would have
> been easy to adopt anti-spam measures that would have made what you do
> impossible, but it wasn't done.

I have the impression you're being blindsided by ideology there. To me,
Bigcorp is like state (minus First Amendment).

> > Spam pressure plus measures making the live of small mail providers
> > [difficult] help centralization.
> 
> This is true.  People also seem to like centralization, unfortunately.
> 
> > This is what I call Emergent Evil. I thon't think there's a single
> > person out there scheming out those things, but a corporation as a
> > whole does come up with that kind of perverse behaviour.
> 
> Better "emergent evil" (I've seen the term elsewhere) than the "devil"
> theory but I don't think it is useful to talk about evil at all.  They
> are just people doing what works for them (even in government, the
> biggest and most powerful bigcorp of all).

I had early and intense religious education. Not trying to offend
anyone, but I had my share of devil and then some. These days I
prefer to make do without :-)

Cheers
-- t


signature.asc
Description: Digital signature


Re: HTML mail

2019-07-12 Thread tomas
On Thu, Jul 11, 2019 at 01:00:11PM -0600, Thomas D Dial wrote:
> On Thu, 2019-07-11 at 14:46 +0200, to...@tuxteam.de wrote:

[...]

> > My bank offers a standardized protocol based on public key
> > cryptography.

[...]

> > No browser involved.
> 
> Can you name the bank? It has annoyed me for between 20 and 30 years
> that banks, generally, have avoided this obvious way to conduct business
> with their customers in favor of more vulnerable methods pushed by their
> enterprise IT suppliers.

Most probably it won't help you -- my guess is that we're at opposite
banks (heh) of the big pond. But FWIW, my bank is GLS bank [1] (which
specializes in ethical investment) and the mentined standard is
HBCI [2].

Cheers

[1] https://www.gls.de/privatkunden/
[2] https://en.wikipedia.org/wiki/HBCI

-- tomás


signature.asc
Description: Digital signature


Re: Preguntas

2019-07-12 Thread Galvatorix Torixgalva
Hola,

nuevo en linux?, pues tranquilo que todos hemos pasado por ahi ;)

a ver, lo que comentas...

"el proceso lo realice desde una maquina virtual primero"
buena idea, sobretodo cuando estas comenzando

"es algo difícil pero no imposible de que afecte directamente a la pc"
quedate tranquilo que VirtualBox y Linux son viejos conocidos y lo que tu
estas haciendo (instalar Debian en VirtualBox) es bastante habitual, el
riesgo de que le pase algo a tu ordenador por eso es muy bajo

"casi finalizando me sale unas letras extrañas"
te refieres a lo que sale en la imagen que has enviado?. Eso podria ser
algun error extraño (y sin importancia real) del instalador. Podrias
revisar tambien la configuracion de la tarjeta de video en virtualbox, por
si acaso.

"¿Es normal que aparezca esto en la instalación?"
no, pero tampoco le des demasiada importancia si no se repite y no sucede
nada mas.

"¿No se dañara mi pc cuando lo instale directamente?"
Si te refieres a que si instalar debian puede causar una averia fisica en
tu ordenador, la respuesta es negativa. Linux en general, y Debian en
particular, es compatible con la inmensa mayoria del hardware que se usa
actualmente, y bastante del hardware relativamente antiguo. En el manual de
Debian (disponible en la web de Debian) tienes los requisitos de hardware.

Si quieres quedarte mas tranquilo podrias probar algun LiveCD como por
ejemplo knoppix. Knoppix es una forma de usar Linux en tu ordenador SIN
instalarlo. Se ejecuta todo en memoria RAM y (insisto) no se instala nada
en el disco duro. Podrias usarlo para ver si todo tu hardware (procesador,
placa base, memoria ram, tarjeta de video, etc) es compatible con linux.
Knoppix basicamente te lo da todo (casi) hecho, solamente te preguntara
algunas cosas basicas.

"Ya que hace tiempo supe que habían problemas con Ubuntu y una versión que
había sido publicada estaba quemando la BIOS  de la pc"
seria importante saber exactamente que ha pasado ahi, con detalles.
especialmente todo lo relacionado con ese ordenador y esa bios

Un detalle final sobre tu ordenador. Me ha llamado la atencion la poca
memoria ram que tiene (512 Megas). Ten eso en cuenta tanto durante la
instalacion como cuando uses linux.

Un saludo


Re: Flatpak or repository apps

2019-07-12 Thread Andrei POPESCU
On Vi, 12 iul 19, 09:33:44, Georgios wrote:
> Hi there!
> 
> Based on security and stability i was wondering what is more preferable?
> 
> Installing apps through flatpak or through debian repositories?

This is quite generic. It would help if you provided concrete examples 
of software that is available both as Debian package and flatpak.
 
> Some thoughts in my mind.
> 
> Repositories:
> 
> -I was thinking that in repositories you have old software that gets
> bugs fixes. But what about old software that it isnt supported? Are
> fixes backported etc? How fast?

Depends on the software.

> -Doesnt offer easy sandboxing like flatpak
> 
> -Apparmor can restrict applications
> 
> 
> Flatpak:
> 
> -sandboxing
> 
> -Propably bug fixes are faster if the developer support flatpak distribution

What makes you assume that?

> -No Apparmor.
> 
> -are the latest applications stable enough?

Depends on the application.

> Any thoughts on the issue?

Some, as per above, but not very helpful without examples.

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


signature.asc
Description: PGP signature


Re: Wpa_supplicant Error: No such device

2019-07-12 Thread Andrei POPESCU
On Jo, 11 iul 19, 19:26:45, Patrick Bartek wrote:
> On Thu, 11 Jul 2019 21:02:44 - (UTC)
> Bert Riding  wrote:
> 
> > You could try using the actual device for the -i option (interface)...like 
> > wlan0 or, in the new notation wlp3s0, and use nl80122 as the -D 
> > option (driver).
> 
> iw dev or ip a report the device name to be wlx00e04c2a23c4.  This
> designation never changes regardless of reboots or which USB port I
> plug the wireless device into.

That is a MAC-based name and is to be expected/makes sense for USB 
adapters.

> I examined the output of dmesg and noted that udev had reassigned 
> wlan0 to this new name.

To or from? I would expect the kernel to assign wlan0 to it and then 
udev to rename it.

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


signature.asc
Description: PGP signature


Flatpak or repository apps

2019-07-12 Thread Georgios
Hi there!

Based on security and stability i was wondering what is more preferable?

Installing apps through flatpak or through debian repositories?

Some thoughts in my mind.

Repositories:

-I was thinking that in repositories you have old software that gets
bugs fixes. But what about old software that it isnt supported? Are
fixes backported etc? How fast?

-Doesnt offer easy sandboxing like flatpak

-Apparmor can restrict applications


Flatpak:

-sandboxing

-Propably bug fixes are faster if the developer support flatpak distribution

-No Apparmor.

-are the latest applications stable enough?


Any thoughts on the issue?



Re: Ansible : User to use

2019-07-12 Thread deloptes
Thierry Leurent wrote:

> I'm beginning to work with Ansible to configure my hosts.
> What is the best practice to run playbooks on all of my Linux host ?
> I must define a specific user ?

Hi,
too generic questions. Read more of the docs and you'll find out.
Basically for configuration purpose of multiple hosts you need a user (ssh)
to access the hosts.

regards



Re: Wpa_supplicant Error: No such device

2019-07-12 Thread Bert Riding
Yes, I'm sorry I didn't mention that my device name was merely an
example.  I wonder if "ip link show" or "ls -l /sys/class/net" or the 
obsolete "ifconfig a" give the same device name.  Udevadm might 
help, too.  "udevadm info -e | grep .wl" for instance.  The name you are 
using is the name using the MAC address, which is the last match as udev 
lists the names, and won't be used if udev finds another name first.  See
https://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/
 

"nl80211" is the correct name of the driver.  I apologize for the error.

On Fri, 12 Jul 2019 04:30:02 +0200, Patrick Bartek wrote:

> On Thu, 11 Jul 2019 21:02:44 - (UTC)
> Bert Riding  wrote:
> 
>> You could try using the actual device for the -i option (interface)...like 
>> wlan0 or, in the new notation wlp3s0, and use nl80122 as the -D 
>> option (driver).
> 
> iw dev or ip a report the device name to be wlx00e04c2a23c4.  This
> designation never changes regardless of reboots or which USB port I
> plug the wireless device into. I examined the output of dmesg and noted
> that udev had reassigned wlan0 to this new name. Don't know why.  And it
> does work when scanning or finding device info or bringing device up or
> down.  But I initially tried wlan0 anyway.  Got "No such
> device . . ." etc.
> 
> I tried using -D nl80211 (did you transpose digits?) and not using it.
> wpa_supplicant failed with the same error noted below.  Also, tried
> wext. Ditto.
> 
> Haven't tried wlp3s0, but haven't found ANY reference to that name
> on the system regardless of which command I use to show network devices.
> 
> Thanks for your input.
> 
> B
> 
>> On Thu, 11 Jul 2019 02:10:02 +0200, Patrick Bartek wrote:
>> 
>> > A problem when trying to associate with a wireless router
>> > (WPA2). Get the following error when manually executing:
>> > 
>> > wpa_supplicant -i wlx
>> > -c /etc/wpa_supplicant/wpa_supplicant.conf
>> > 
>> > Could not read interface wlx flags: No such device
>> > nl80211: Driver does not support authentication/association or connect
>> > commands
>> > nl80122: [can't read my own writing on this one]
>> > 
>> > Wpa_supplicant fails whether I use the -B (background) switch or not.
>> > 
>> > Here's the wpa_supplicant.conf file:
>> > 
>> > 
>> > ctrl_interface=DIR=/run/wpa_supplicant
>> > update_config=1
>> > 
>> > network={
>> >ssid="ROUTERNAME"
>> > #  scan_ssid=1
>> > #  key_mgmt=WPA-PSK
>> > #  psk="SECRETPASSPHRASE"
>> >psk=longhexnumber
>> > }
>> > 
>> > I've tried with and without the commented lines.  Same results.
>> > 
>> > Here's the wifi portion of my /etc/network/interfaces
>> > 
>> > allow-hotplug wlx
>> > iface wlx inet dhcp
>> >wpa-ssid ROUTERNAME
>> > #  wpa-key-mgmt WPA-PSK
>> > #  wpa-group TKIP CCMP
>> > #  wpa-psk SECRETPASSPHRASE
>> >wpa-psk longhexnumber
>> > 
>> > The wireless is a Rosewill USB RNX-N180UBEv3. It is UP after boot and
>> > scanning wifi routers works.  System tries to associate to router at
>> > boot, but fails.  Correct kernel module (rtl8192eu) is loaded.
>> > 
>> > Anyone got an idea of why wpa_supplicant is failing?  And how to fix
>> > it?  All commands issued as root.
>> > 
>> > FYI: I have an atypical Stretch install: No desktop environment,
>> > window manager only; sysvinit, but systemd libraries still installed.
>> > Boots to terminal, login there, then startx, if I want a GUI.  Wifi UP
>> > at terminal and scanning works. This is not a laptop.  Wired ethernet
>> > works and has always (12 years) worked.
>> > 
>> > Thanks.
>> > 
>> > B  
>>



Re: Preguntas

2019-07-12 Thread Fran Torres
Buenas,

Podrías poner el resultado de la instalación (donde está el problema)
en texto en lugar de una imagen?

Fran.

El 12/7/19, Omar David Colmenarez Calabuig.  escribió:
> Buenas noches, me gustaría  que me aclararan una duda que tengo en el
> proceso de instalación de Debian 10, yo ya he instalado este sistema
> operativo anteriormente en otras versiones y no me ha dado problema alguno,
> ahora que me gustaría descargar la ultima actualización de este sistema me
> encuentro que cuando ya tengo todo listo y casi finalizando me sale unas
> letras extrañas, el proceso lo realice desde una maquina virtual primero ya
> que por lo que he leído es algo difícil pero no imposible de que afecte
> directamente a la pc, aunque aclaro "que no llegue a instalarlo en la
> maquina virtual" por si me llegaba afectar directamente algo en el
> ordenador ya que se comparten los procesadores y la memoria RAM del
> ordenador en físico, ahora me gustaría que me aclararan lo siguiente. ¿Es
> normal que aparezca esto en la instalación?¿No se dañara mi pc cuando lo
> instale directamente? Ya que hace tiempo supe que habían problemas con
> Ubuntu y una versión que había sido publicada estaba quemando la BIOS  de
> la pc. Acá les dejo unos datos sobre mi pc.
> Su fabricante es Dell.
> Modelo: OptiPlex GX260.
> RAM: 512 MB.
> Versión y fecha del BIOS: DELL A09,  01/11/2004
> Procesador: Intel Pentium 4, 2 GHz, 1 Procesador
> Arquitectura: X86 (32 bits)
> Se que la instalación se me ejecuto en modo "Baja memoria" y entiendo que
> sea por falta de mas memoria RAM, sera por eso la causa de este problema?
> Soy nuevo usuario en Linux, a pesar de que  haya instalado una vez su
> operativo Debian no he tenido tiempo suficiente en aprenderlo, y ahora me
> gustaría volver a retornar lo que he estado aprendiendo sobre este sistema.
>
> Espero que me puedan aclarar las dudas que tengo, Gracias por su
> información.
>
> [image: Proceso de instalacion Debian 10.png]
>