Re: need help with sftp

[mick crane]

On 2018-08-08 02:54, Fred wrote:

On 08/07/2018 12:30 PM, Greg Wooledge wrote:

On Tue, Aug 07, 2018 at 12:15:34PM -0700, Fred wrote:
I need to ftp some files from a new Sid installation to either of two 
other
computers on the network.  Neither is configured for a "secure" 
version of

ftp and there is no reason to do that and Sid only has sftp.

If you only need an FTP client, that's easy enough.  You can use the
program "ftp" or if you want more features, you can install lftp and
use that.

The "ftp" package (which provides one of the possible /usr/bin/ftp 
client

programs) has standard priority, so it should be installed already.



Hi,

I am abandoning this as I found another way to transfer the files.
Thanks for the help!


the easy way to share files is to setup ssh sshd with keys with a 
passphrase and use scp to move the files about or putty and Winscp on 
windows


mick




Best regards,
Fred


--
Key ID4BFEBB31

Re: problem with modern desktops on Buster

[Gary Dale]

On 2018-08-07 07:13 AM, Jonathan Dowland wrote:

On Mon, Aug 06, 2018 at 03:03:57PM -0400, Gary Dale wrote:
I'm not even sure where to report this problem since I can't identify 
a specific package that is causing it. However since Gnome Flashback 
seems to be working, I'd guess that it is in the flashier desktop 
elements.


You can report a bug against the pseudo-package "general" if you aren't
sure what's at fault, but it's possibly better to ask here first, as you
have, to see if people can help narrow down the problem.

What graphics hardware do you have (e.g. nvidia), and have you installed
any drivers from outside Debian to use it?

Thanks. I'm thrilled to report that I'm back in Plasma and it is 
behaving itself again (so far) after doing the latest full-upgrade.


As for non-debian drivers, I don't have any. The worst I've done is 
include non-free firmware for my NIC.


Despite my earlier success with Gnome Flashback, it took to locking up 
when I tried to bring the computer back after the screen saver kicked 
in. Turning off the suspend mode cured that. I note that under KDE, I 
actually have just been locking the screen.


Hopefully whatever nastiness caused me two days of pain using Gnome 
Flashback has been resolved.

Re: need help with sftp

[Fred]

On 08/07/2018 12:30 PM, Greg Wooledge wrote:

On Tue, Aug 07, 2018 at 12:15:34PM -0700, Fred wrote:

I need to ftp some files from a new Sid installation to either of two other
computers on the network.  Neither is configured for a "secure" version of
ftp and there is no reason to do that and Sid only has sftp.

If you only need an FTP client, that's easy enough.  You can use the
program "ftp" or if you want more features, you can install lftp and
use that.

The "ftp" package (which provides one of the possible /usr/bin/ftp client
programs) has standard priority, so it should be installed already.



Hi,

I am abandoning this as I found another way to transfer the files.  
Thanks for the help!


Best regards,
Fred

RE: Debian>=9.5 + APACHE2>=2.4.25 + HTTP/2

[tech]

anyone ??


De : tech 
Envoyé : vendredi 3 août 2018 05:53:55
À : debianusers
Objet : Debian>=9.5 + APACHE2>=2.4.25 + HTTP/2


Hello world,



As the Apache MPM (Multi-Processing Module) prefork no longer supports HTTP/2 
and having updated to 9.5 (breaking my fully working HTTP/2 server), i wonder 
what are the plan for HTTP/2 support.


Is it better to wait for a fix ?

If so, when ?


Is it better to forget MPM, witch i dont know how to do it ( yes, this is 
August and i am lazy )


switching to nginx might be an option, but again, i am lazy...


Thanks.

Re: [OT] Whatsapp libre bajo debian

[Fabián Bonetti]

##Servidor Debian vivo desde 2009##  Friendica > 
https://friendica.mamalibre.com.ar   Whatsapp libre > 
http://xmpp.mamalibre.com.ar  Hosting free > http://sitios.mamalibre.com.ar  
Gnusocial > http://legadolibre.mamalibre.com.ar  Plus > 
http://mamalibre.com.ar/plus  ### 

 Mensaje original De: Saúl Morales  
Fecha: 7/8/2018  22:00  (GMT-03:00) Para: mama21m...@riseup.net Asunto: Re: 
[OT] Whatsapp libre bajo debian 
otra cosa algun dia podrian crear un antivirus popular bajo gpl o es imposible

El mar., 7 de ago. de 2018 a la(s) 21:59, Saúl Morales (ezequiel@gmail.com) 
escribió:
la otra cosa es si es muy popular o recien emppiesa esa aplicacion de wapsap

El mar., 7 de ago. de 2018 a la(s) 21:55, Saúl Morales (ezequiel@gmail.com) 
escribió:
vos me queres decir que es mejor y es mejor telegram ?= y otra cosa mas ese 
wapsap libre es de la empresa de wapsap y otra cosa mas este...

El mar., 7 de ago. de 2018 a la(s) 17:26, Fabián Bonetti 
(mama21m...@riseup.net) escribió:
On Tue, 7 Aug 2018 15:30:17 -0300

Saúl Morales  wrote:



> lo puedo bajar como una aplicacion de apptore de android

> 

> El mar., 7 de ago. de 2018 a la(s) 15:29, Saúl Morales (

> ezequiel@gmail.com) escribió:

> 

> > negro , no entiendo que vos decis que ese wapsap es libre de gnu es  la

> > contra de wapsap??

> >

> > El lun., 6 de ago. de 2018 a la(s) 00:30, Fabián Bonetti (

> > mama21m...@riseup.net) escribió:

> >

> >>

> >>

> >>

> >>

> >>

> >> ##Servidor Debian vivo desde 2009##

> >> Friendica > https://friendica.mamalibre.com.ar

> >> Whatsapp libre > http://xmpp.mamalibre.com.ar

> >> Hosting free > http://sitios.mamalibre.com.ar

> >> Gnusocial > http://legadolibre.mamalibre.com.ar

> >> Plus > http://mamalibre.com.ar/plus

> >> ###

> >>

> >>

> >>  Mensaje original 

> >> De: Sebastian Oldani 

> >> Fecha: 5/8/2018 19:39 (GMT-03:00)

> >> Para: Debian 

> >> Asunto: Re: [OT] Whatsapp libre bajo debian

> >>

> >> El dom, 05-08-2018 a las 18:03 -0300, Fabián Bonetti escribió:

> >>

> >>

> >> Conversations Legacy

> >>

> >> Conversations Legacy (Chat using the XMPP network) -

> >> https://f-droid.org/app/eu.siacs.conversations.legacy

> >>

> >> Voice Recorder Plugin

> >>

> >> Voice Recorder Plugin (Send audio messages via Conversations) -

> >> https://f-droid.org/app/eu.siacs.conversations.voicerecorder

> >>

> >> El primero es la app para android, el segundo es el plugin para que

> >> puedas mandar mensajes de audio.

> >>

> >> Con un buen servidor como http://xmpp.mamalibre.com.ar obtenemos nuestra

> >> alternativa libre a  whatsapp. 

> >>

> >>

> >>

> >> Hola, si esta muy bueno, yo lo uso, complemento con algunas cosas...

> >> Hay una lista de servidores donde registrarse, la mayoría no te piden

> >> ningún dato personal y podes hablar con gente registrada en otros

> >> servidores (salvo excepciones)

> >>

> >> https://list.jabber.at/

> >>

> >> La mayoría soporta varios tipos de encriptación

> >>

> >> Con respecto a conversations, se puede descargar la versión gratuita

> >> desde playstore, que es la versión vieja, para la versión nueva hay que

> >> pagar unos dolares. Aunque tambien se puede descargar desde github y

> >> compilarla uno mismo para obtenerla gratis. También se puede descargar

> >> gratis desde f-droid, acá tienen la ultima version gratis

> >>

> >> Tambien hay clientes web, y aplicaciones para todos los sistemas

> >> operativos, y hay librerías para javascript para embeber un cliente en una

> >> web, y también esta la librería libgloox para crear bots o aplicaciónes

> >>

> >> Dejo los links!

> >>

> >> https://conversations.im/

> >>

> >> git clone https://github.com/siacs/Conversations.git

> >>

> >> https://f-droid.org/repo/eu.siacs.conversations_280.apk //Esta version

> >> no requiere de los plugins para voice ni maps. Ya vienen incluidos!!!

> >>

> >> https://conversejs.org/ //Cliente web que

> >> permite embeberlo en una página web

> >>

> >> Mi servidor favorito: https://404.city/

> >>

> >> Tambien la deja la entrada a la wikipedia de xmpp, que hay datos

> >> realmente interesantes para alguien que quiera aprender más

> >>

> >> https://es.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol

> >>

> >> Saludos!

> >> Espero les guste la info!

> >>

> >> -

> >>

> >> Si...tambien esta la aplicacion para pc y android muy buena llamada

> >> astrachat...su licencia no es libre. Pero soporta lo mismo que

> >> whatsapphasta llamadas. Solo se nececuta una cuenta jabber.

> >>

> >> Saludos

> >>

> >



Si esta en play store se llama conversation.



Pero en este repo esta mas completo



.- Conversation (con plugin audio y mapas)

Licencia GNU



git clone https://github.com/siacs/Conversations.git





https://f-droid.org/repo/eu.siacs.conversations_280.apk 

Esta version 

Re: Kernel 4.9.0-7-686 Installed RAM vs. uabale RAM

[Michael Stone]

On Wed, Aug 08, 2018 at 12:25:14AM +0200, deloptes wrote:

Pascal Hambourg wrote:


 But you need a
686-pae or amd64 kernel to use RAM beyond 4 GiB, as Michael pointed out.


but he has 3GB and machine sees only 2 - is it because kernel is not pae?
I was thinking that 686 system can see (and use) around 3GB and with some
trick above, but in case of 4GB it did not make any sense from technical
point of view, because much of it is lost for reserved mapping tables
(AFAIR). So mem is optimal on that machine, but why it can see only 2 of 3?
Is one GB shared with graphics controller?


Short answer is yes, all 3GB should show up. Why isn't it? No idea. dmesg 
would help, lscpu would help, knowing whether all 3GB is seen in the 
system's bios would help. PAE kernel might help, and performance with 
3GB RAM and no PAE will be really terrible anyway. The only reason to 
run a non-PAE kernel would be if the CPU is too old to support PAE. (In 
which case there may be any number of reasons why things are flaky on 15 
or 20 year old hardware.)


If this is a really, really old machine and just an experiment, carry 
on. With reasonably modern hardware the right answer for >1G RAM is an 
amd64 kernel. If you have an (unusual) need to run an i386 userspace 
you can install the amd64 kernel on i386 system. All of the options for 
running >1G on 32 bit kernel have pretty severe performance impact. 

It's possible that memory has been reserved for an on-board GPU, but I'm 
having trouble wrapping my head around the idea of a machine that 
memory-limited using a gig of video memory. dmesg would help understand 
that. I lean toward suspecting the chipset just doesn't support >2G, but 
knowing what the BIOS reports would clear that up.


Mike Stone

Re: comment récupérer altgr au clavier

[Bernard Schoenacker]

- Mail original -
> De: "Alexandre Hoïde" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mardi 7 Août 2018 21:53:40
> Objet: Re: comment récupérer altgr au clavier
> 
> On Tue, Aug 07, 2018 at 06:22:29PM +0200, Bernard Schoenacker wrote:
> > j'ai réessayé avec la commande showkey -s et je n'ai pas de signal
> > le clavier est cuit ...
> 
>   Dommage ! Ça me fait penser qu'il faudrait que j'installe une
>   distrib
> GNU/Linux sur mon Asus TF300T… mais je crois que la touche 'P' du
> clavier a laché (bien que je ne m'en sois que très peu servi).
> 
>   Bref, désolé pour ton eee.
> 
> --
>  ___
> | $ post_tenebras ↲ | waouh!
> | GNU\ /|\
> |  -- * --  | o
> | $ who ↲/ \|_-- ~_|
> | Alexandre Hoïde   |  _/| |
>  ---
> 

bonjour,

je compte faire remplacer le clavier ultérieurement ...

et il coute environ 30€ maxi + main d'oeuvre

pour ton ordi :
https://linuxontablets.tuxfamily.org/ASUS_Transformer_Pad_TF300T

désolé mais la doc date de 2013

et j'ai trouvé ton clavier :
https://www.ebay.fr/itm/Clavier-Francais-Asus-Transformer-Pad-TF300T-TF300TG-TF300TL-Serie-NEUF-Original/331446257228?hash=item4d2bbc864c:g:~xUAAOSw1ZBUs~OS

merci
slt
bernard

Re: Kernel 4.9.0-7-686 Installed RAM vs. uabale RAM

[deloptes]

Pascal Hambourg wrote:

>  But you need a
> 686-pae or amd64 kernel to use RAM beyond 4 GiB, as Michael pointed out.

but he has 3GB and machine sees only 2 - is it because kernel is not pae?
I was thinking that 686 system can see (and use) around 3GB and with some
trick above, but in case of 4GB it did not make any sense from technical
point of view, because much of it is lost for reserved mapping tables
(AFAIR). So mem is optimal on that machine, but why it can see only 2 of 3?
Is one GB shared with graphics controller?

regards

Re: [solved?] Re: New `no sound' problems

[deloptes]

Rodolfo Medina wrote:

> I `aptitude purge-d' pulseaudio and... (after maybe reboot) sound back
> again...
> 

usually it helps 
logout
remove .pulse from use home
reboot

in .pulse and previously in .config/pulse (AFAIR) there are/were internal DB
and it did not work well after (major) upgrades.

regards

Re: New `no sound' problems

[deloptes]

Curt wrote:

> He means it's self-explanatory given you're using testing and when using
> testing shit happens (things break)

its not even testing it is sid - as far as I know it is after testing and
there even more shit happens, so I don't understand why he/she should
bother us or we should bother answering.
This definitely is not a user query but rather something that goes to
package/support etc.

For example I play with newer kernels from time to time and last time I
compiled/installed 4.16 it broke sound - I was seeing the devices twice in
all mixers - so I stayed on 4.15 for a while. I now compiled 4.17
(yesterday) and all works just fine.

Sid may work today but not tomorrow - this is the purpose of sid and if you
are not debuggin/testing for debian, I am not sure you want to run anything
on sid 

regards

Re: luks, crypttab: why 3 partition only 2 passphrases entered

[Carles Pina i Estany]

Hi,

On Aug/07/2018, Jonathan Dowland wrote:
> On Sat, Aug 04, 2018 at 10:54:59PM +0100, Carles Pina i Estany wrote:
> > 
> > And I'm now 99% sure that the culprit of all this confusion is...
> > plymouth! It has a password caching facility and systemd seems to use it
> > to get the cached password.
> 
> Almost certainly, yes, although, if plymouth is passing the password
> through to systemd, then it need not be caching it itself, as systemd
> caches disk passwords for a short while (I think 5 minutes if I recall
> correctly). See systemd-ask-password(1) for an introduction to the
> architecture of systemd's password stuff.

I did some further digging after sending my last message.

The Debian initrd scripts use Plymouth (if installed, of course, else
other methods... I had it installed) to ask the user for passwords and
try to mount the root partition and minimum partitions.

When Debian initrd scripts are finished they execute systemd which will
request from plymouthd the cached passwords (using a local socket I
think). They can be seen if adding: ply_trace("Carles password: %s",
password); in the while (node != NULL) after 'ply_trace ("There are %d
cached passwords",' (I should have had git for these changes :-) ) (in
ply_boot_connection_on_request function).

(also passing "debug" to the kernel, then journalct to see the plymouth
debug messages).

All the passwords are cached, even invalid ones: Plymouth doesn't know
if they were valid or not and the Debian scripts doesn't invalidate
them, not even sure if Plymouth supports invalidation of passwords :)

Systemd requests all the cached passwords from plymouthd.

Then systemd tries to mount the other partitions with the requested
passwords, if it works it will add the passwords in the Kernel keyring
and can it can be seen with:
root@pinux:~# keyctl show
Session Keyring
 696839878 --alswrv  0 65534  keyring: _uid_ses.0
 373345068 --alswrv  0 65534   \_ keyring: _uid.0
 600178798 --alswrv  0 0   \_ user: cryptsetup
root@pinux:~# 

(this can be tested in my system at any time with:
systemctl stop systemd-cryptsetup@ssd_dades_crypt.service
systemctl start systemd-cryptsetup@ssd_dades_crypt.service
keyctl show

or just stop, start (enter password), stop, start (password not needed
because already in the keyring, I thnk that 5 minutes by default)

That was quite lot of fun!

Cheers,

-- 
Carles Pina i Estany
Web: http://pinux.info || Blog: http://pintant.cat
GPG Key 0x8CD5C157

Re: Please help with error message

[deloptes]

Rodolfo Medina wrote:

> I'd always thought that `su' was Debian's and `sudo' was Ubuntu's...  :-)

No - both are linux and sudo is for the use to be able to use specific
commands. So in general I add sudo rule for my use for bash and it is done.
Alternatively add user to sudo group and you can use the factory rule

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

There is nothing like ubuntu or debian relationship here.

regards

Re: [testing] su - et X

[Gaëtan Perrier]

Le mardi 07 août 2018 à 10:42 +0200, Christophe Maquaire a écrit :
> Le mardi 07 août 2018 à 10:11 +0200, Bernardo a écrit :
> > Celle-ci ? (mais je suis en Sid)
> 
> On dirait bien, merci.
> 
> Christophe
> 

Par contre je ne vois pas trop le lien avec mon soucis ?

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: Kernel 4.9.0-7-686 Installed RAM vs. uabale RAM

[Pascal Hambourg]

Le 07/08/2018 à 14:53, basti a écrit :

Hello, I have a system with Kernel 4.9.0-7-686, installed RAM are 3x 1GB
but free -m only show 2GB.

Whats wrong here?

(...)

As I know 686 can address 4GB RAM


No. It can address 4 GiB memory space. Memory space does not contain 
only RAM, it is also used to address system devices such as the graphics 
controller. The part of the memory address space which is reserved for 
system devices is often called "PCI hole". Some motherboards reserve a 
very large amount of address space for the PCI hole, up to 2 GiB as I 
have already seen. When you are lucky, the RAM which cannot be mapped in 
the PCI hole can be remapped beyond the 4 GiB boundary. Sometimes it 
requires to enable an option in the BIOS settings. But you need a 
686-pae or amd64 kernel to use RAM beyond 4 GiB, as Michael pointed out.

Re: [OT] Whatsapp libre bajo debian

[Fabián Bonetti]

On Tue, 7 Aug 2018 15:30:17 -0300
Saúl Morales  wrote:

> lo puedo bajar como una aplicacion de apptore de android
> 
> El mar., 7 de ago. de 2018 a la(s) 15:29, Saúl Morales (
> ezequiel@gmail.com) escribió:
> 
> > negro , no entiendo que vos decis que ese wapsap es libre de gnu es  la
> > contra de wapsap??
> >
> > El lun., 6 de ago. de 2018 a la(s) 00:30, Fabián Bonetti (
> > mama21m...@riseup.net) escribió:
> >
> >>
> >>
> >>
> >>
> >>
> >> ##Servidor Debian vivo desde 2009##
> >> Friendica > https://friendica.mamalibre.com.ar
> >> Whatsapp libre > http://xmpp.mamalibre.com.ar
> >> Hosting free > http://sitios.mamalibre.com.ar
> >> Gnusocial > http://legadolibre.mamalibre.com.ar
> >> Plus > http://mamalibre.com.ar/plus
> >> ###
> >>
> >>
> >>  Mensaje original 
> >> De: Sebastian Oldani 
> >> Fecha: 5/8/2018 19:39 (GMT-03:00)
> >> Para: Debian 
> >> Asunto: Re: [OT] Whatsapp libre bajo debian
> >>
> >> El dom, 05-08-2018 a las 18:03 -0300, Fabián Bonetti escribió:
> >>
> >>
> >> Conversations Legacy
> >>
> >> Conversations Legacy (Chat using the XMPP network) -
> >> https://f-droid.org/app/eu.siacs.conversations.legacy
> >>
> >> Voice Recorder Plugin
> >>
> >> Voice Recorder Plugin (Send audio messages via Conversations) -
> >> https://f-droid.org/app/eu.siacs.conversations.voicerecorder
> >>
> >> El primero es la app para android, el segundo es el plugin para que
> >> puedas mandar mensajes de audio.
> >>
> >> Con un buen servidor como http://xmpp.mamalibre.com.ar obtenemos nuestra
> >> alternativa libre a  whatsapp. 
> >>
> >>
> >>
> >> Hola, si esta muy bueno, yo lo uso, complemento con algunas cosas...
> >> Hay una lista de servidores donde registrarse, la mayoría no te piden
> >> ningún dato personal y podes hablar con gente registrada en otros
> >> servidores (salvo excepciones)
> >>
> >> https://list.jabber.at/
> >>
> >> La mayoría soporta varios tipos de encriptación
> >>
> >> Con respecto a conversations, se puede descargar la versión gratuita
> >> desde playstore, que es la versión vieja, para la versión nueva hay que
> >> pagar unos dolares. Aunque tambien se puede descargar desde github y
> >> compilarla uno mismo para obtenerla gratis. También se puede descargar
> >> gratis desde f-droid, acá tienen la ultima version gratis
> >>
> >> Tambien hay clientes web, y aplicaciones para todos los sistemas
> >> operativos, y hay librerías para javascript para embeber un cliente en una
> >> web, y también esta la librería libgloox para crear bots o aplicaciónes
> >>
> >> Dejo los links!
> >>
> >> https://conversations.im/
> >>
> >> git clone https://github.com/siacs/Conversations.git
> >>
> >> https://f-droid.org/repo/eu.siacs.conversations_280.apk //Esta version
> >> no requiere de los plugins para voice ni maps. Ya vienen incluidos!!!
> >>
> >> https://conversejs.org/ //Cliente web que
> >> permite embeberlo en una página web
> >>
> >> Mi servidor favorito: https://404.city/
> >>
> >> Tambien la deja la entrada a la wikipedia de xmpp, que hay datos
> >> realmente interesantes para alguien que quiera aprender más
> >>
> >> https://es.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
> >>
> >> Saludos!
> >> Espero les guste la info!
> >>
> >> -
> >>
> >> Si...tambien esta la aplicacion para pc y android muy buena llamada
> >> astrachat...su licencia no es libre. Pero soporta lo mismo que
> >> whatsapphasta llamadas. Solo se nececuta una cuenta jabber.
> >>
> >> Saludos
> >>
> >

Si esta en play store se llama conversation.

Pero en este repo esta mas completo

.- Conversation (con plugin audio y mapas)
Licencia GNU

git clone https://github.com/siacs/Conversations.git


https://f-droid.org/repo/eu.siacs.conversations_280.apk 
Esta version tiene los plugins para voice y maps. 
Ya vienen incluidos! 
Para mandar audio muy bueno.

-- 
Servicios:. http://mamalibre.com.ar/plus
MamaLibre, Casa en Lincoln, Ituzaingo 1085 CP6070, Buenos Aires, Argentina

Re: [OT] Whatsapp libre bajo debian

[Fabián Bonetti]

On Tue, 7 Aug 2018 15:29:21 -0300
Saúl Morales  wrote:

> negro , no entiendo que vos decis que ese wapsap es libre de gnu es  la
> contra de wapsap??
> 
> El lun., 6 de ago. de 2018 a la(s) 00:30, Fabián Bonetti (
> mama21m...@riseup.net) escribió:
> 
> >
> >
> >
> >
> >
> > ##Servidor Debian vivo desde 2009##
> > Friendica > https://friendica.mamalibre.com.ar
> > Whatsapp libre > http://xmpp.mamalibre.com.ar
> > Hosting free > http://sitios.mamalibre.com.ar
> > Gnusocial > http://legadolibre.mamalibre.com.ar
> > Plus > http://mamalibre.com.ar/plus
> > ###
> >
> >
> >  Mensaje original 
> > De: Sebastian Oldani 
> > Fecha: 5/8/2018 19:39 (GMT-03:00)
> > Para: Debian 
> > Asunto: Re: [OT] Whatsapp libre bajo debian
> >
> > El dom, 05-08-2018 a las 18:03 -0300, Fabián Bonetti escribió:
> >
> >
> > Conversations Legacy
> >
> > Conversations Legacy (Chat using the XMPP network) -
> > https://f-droid.org/app/eu.siacs.conversations.legacy
> >
> > Voice Recorder Plugin
> >
> > Voice Recorder Plugin (Send audio messages via Conversations) -
> > https://f-droid.org/app/eu.siacs.conversations.voicerecorder
> >
> > El primero es la app para android, el segundo es el plugin para que puedas
> > mandar mensajes de audio.
> >
> > Con un buen servidor como http://xmpp.mamalibre.com.ar obtenemos nuestra
> > alternativa libre a  whatsapp. 
> >
> >
> >
> > Hola, si esta muy bueno, yo lo uso, complemento con algunas cosas...
> > Hay una lista de servidores donde registrarse, la mayoría no te piden
> > ningún dato personal y podes hablar con gente registrada en otros
> > servidores (salvo excepciones)
> >
> > https://list.jabber.at/
> >
> > La mayoría soporta varios tipos de encriptación
> >
> > Con respecto a conversations, se puede descargar la versión gratuita desde
> > playstore, que es la versión vieja, para la versión nueva hay que pagar
> > unos dolares. Aunque tambien se puede descargar desde github y compilarla
> > uno mismo para obtenerla gratis. También se puede descargar gratis desde
> > f-droid, acá tienen la ultima version gratis
> >
> > Tambien hay clientes web, y aplicaciones para todos los sistemas
> > operativos, y hay librerías para javascript para embeber un cliente en una
> > web, y también esta la librería libgloox para crear bots o aplicaciónes
> >
> > Dejo los links!
> >
> > https://conversations.im/
> >
> > git clone https://github.com/siacs/Conversations.git
> >
> > https://f-droid.org/repo/eu.siacs.conversations_280.apk //Esta version no
> > requiere de los plugins para voice ni maps. Ya vienen incluidos!!!
> >
> > https://conversejs.org/ //Cliente web que
> > permite embeberlo en una página web
> >
> > Mi servidor favorito: https://404.city/
> >
> > Tambien la deja la entrada a la wikipedia de xmpp, que hay datos realmente
> > interesantes para alguien que quiera aprender más
> >
> > https://es.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
> >
> > Saludos!
> > Espero les guste la info!
> >
> > -
> >
> > Si...tambien esta la aplicacion para pc y android muy buena llamada
> > astrachat...su licencia no es libre. Pero soporta lo mismo que
> > whatsapphasta llamadas. Solo se nececuta una cuenta jabber.
> >
> > Saludos
> >

Cuando digo Whatsapp libre es solo para llamar la atención. 

En realidad es una aplicacion de software libre que hace lo mismo que whatsapp.

-- 
Servicios:. http://mamalibre.com.ar/plus
MamaLibre, Casa en Lincoln, Ituzaingo 1085 CP6070, Buenos Aires, Argentina

Re: As seen above: use of su vs sudo

[Gene Heskett]

On Tuesday 07 August 2018 15:08:34 Nemeth Gyorgy wrote:

> 2018-08-07 14:50 keltezéssel, The Wanderer írta:
> > But it's more secure to require a second password to do elevated
> > things than to permit doing those things with the same password as
> > is used for ordinary activities.
>
> Then use other pam backend module for sudo and not the 'common-auth'.
> There are lot of pam auth methods. You only have to create a second
> database which is supported by some of the libpam modules and modify
> /etc/pam.d/sudo
>
> In this case you still don't have to share a common root password
> (which is really bad) and can require a second password for doing
> elevated things.

How to do that should be written up and published at a google findable 
site as this idea seems to offer an additional layer of security.  But 
one that you can still remember w/o painting it on the wall. I have one 
jessie machine that has a long root pw,  but sudo hasn't needed a pw 
since a long time. Nor does it advise you in the shell prompt that its a 
sudo -i empowered shell, and that bothers the hell outta me. Haveing 
sudo ask for yet a 3rd password phrase of 60 or more chars (with no 
objections to a word separating space here and there) to become active 
seems like a good thing for security.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: comment récupérer altgr au clavier

[Alexandre Hoïde]

On Tue, Aug 07, 2018 at 06:22:29PM +0200, Bernard Schoenacker wrote:
> j'ai réessayé avec la commande showkey -s et je n'ai pas de signal
> le clavier est cuit ...

  Dommage ! Ça me fait penser qu'il faudrait que j'installe une distrib
GNU/Linux sur mon Asus TF300T… mais je crois que la touche 'P' du
clavier a laché (bien que je ne m'en sois que très peu servi).

  Bref, désolé pour ton eee.

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: need help with sftp

[Greg Wooledge]

On Tue, Aug 07, 2018 at 12:15:34PM -0700, Fred wrote:
> I need to ftp some files from a new Sid installation to either of two other
> computers on the network.  Neither is configured for a "secure" version of
> ftp and there is no reason to do that and Sid only has sftp.

If you only need an FTP client, that's easy enough.  You can use the
program "ftp" or if you want more features, you can install lftp and
use that.

The "ftp" package (which provides one of the possible /usr/bin/ftp client
programs) has standard priority, so it should be installed already.

Re: need help with sftp

[Fred]

On 08/07/2018 10:20 AM, Greg Wooledge wrote:

On Tue, Aug 07, 2018 at 09:53:57AM -0700, Fred wrote:

On a new Sid installation I need to ftp some files to another computer on
the network.  sftp appears to be the only ftp program available.  The other
computers on the network do not use ssl so the ftp connection is refused
from both directions.  One computer is using vsftp under Jessie.  I don't
see any option that makes sftp just do plain ordinary ftp.  Is this
hopeless?

https://mywiki.wooledge.org/FtpMustDie

SFTP and FTP are completely different protocols.  They have nothing in
common except 3 letters in their names.

SFTP is implemented on the server side by sshd.  You connect with an SFTP
client (e.g. the sftp command, or an sshfs mounted file system) using
the same credentials that you would use for a regular ssh session.  SFTP
is encrypted, it can be tunnelled through a firewall, etc.

FTP has none of those features.

If you actually *need* to use FTP for some reason (legacy systems on the
network), note first that Debian does NOT install an FTP server package
by default, but it offers several of them.  You can choose one, and
install it, and then you will be able to make FTP connections to your
Debian system.  Authentication will be done using whatever your chosen
FTP server package uses.  Traffic will be unencrypted, and will fly
around in random directions depending on which mode you use, and everything
will fall apart when there are firewalls between client and server.

If you think that you need FTP because of Microsoft Windows systems,
please note that there are many user-friendly graphical SFTP clients
for Microsoft Windows.  You are probably not restricted to its built-in
FTP client.



Hi,
I need to ftp some files from a new Sid installation to either of two 
other computers on the network.  Neither is configured for a "secure" 
version of ftp and there is no reason to do that and Sid only has sftp.  
I would be happy to install a less secure ftp package on the Sid 
installation but will need help doing that instead.  The default sources 
list for Sid apparently needs to be changed so that packages can be 
installed.  I have not had time to research that yet.


I do not use Bill Gates' cancerous, virus-infested, scourge of the Earth 
excuse for an OS!

Best regards,
Fred

Re: As seen above: use of su vs sudo

[Nemeth Gyorgy]

2018-08-07 14:50 keltezéssel, The Wanderer írta:
>
> But it's more secure to require a second password to do elevated things
> than to permit doing those things with the same password as is used for
> ordinary activities.

Then use other pam backend module for sudo and not the 'common-auth'.
There are lot of pam auth methods. You only have to create a second
database which is supported by some of the libpam modules and modify
/etc/pam.d/sudo

In this case you still don't have to share a common root password (which
is really bad) and can require a second password for doing elevated things.

Re: Problema con kvm-qemu

[Felix Perez]

El mar., 7 de ago. de 2018 a la(s) 11:39, AFS (abe...@gmail.com) escribió:
>
> Que tal Felix,  efectivamente intente subirle la RAM pero el sistema se 
> vuelve mas inestable, cuando me refiero al sistema me refiero a mi PC Fisica, 
> no a la virtual.
>

Y un TOP o HTOP que te muestra acerca de quien esta consumiendo los recursos?

Saludos.

> Saludos.
>
> El 7 de agosto de 2018, 09:23, Felix Perez 
> escribió:
>>
>> El mar., 7 de ago. de 2018 a la(s) 09:53, AFS (abe...@gmail.com) escribió:
>> >
>> > Gracias por contestar Eduardo.  Revisando el log no hay nada raro y acabo 
>> > de instalar el sistema, no he actualizado nada.
>> >
>>
>> Hola, probaste ampliando la mem asignada a la VM? Me paso con
>> virtualbox en una oportunidad que si le asignaba poca RAM al sistema
>> virtualizado, el sistema principal se arrastraba, si le aumentaba la
>> ram se normalizaba.  No te puedo aportar mayores antecedentes ya que
>> era en una maquina de pruebas y no le dí mayor importancia y además no
>> me sucedió nunca más.
>>
>> Suerte.
>>
>>
>> > Saludos
>> >
>> > El 7 de agosto de 2018, 08:37, Eduardo Visbal 
>> > escribió:
>> >>
>> >> Los Log del sistema te muestran algo fuera de lo normal?
>> >> Esta lentitud fue a raíz de alguna actualización del sistema?
>> >>
>> >> Eduardo Visbal
>> >> Linuxero #440451
>> >> http://esdebianfritto.blogspot.com/
>> >>
>> >>
>> >> El mar., 7 ago. 2018 a las 9:30, AFS () escribió:
>> >>>
>> >>> Si soporta Virtualizacion.
>> >>>
>> >>> cat /proc/cpuinfo
>> >>> processor: 0
>> >>> vendor_id: AuthenticAMD
>> >>> cpu family: 21
>> >>> model: 2
>> >>> model name: AMD FX(tm)-6300 Six-Core Processor
>> >>> stepping: 0
>> >>> microcode: 0x600081c
>> >>> cpu MHz: 1793.726
>> >>> cache size: 2048 KB
>> >>> physical id: 0
>> >>> siblings: 6
>> >>> core id: 0
>> >>> cpu cores: 3
>> >>> apicid: 16
>> >>> initial apicid: 0
>> >>> fpu: yes
>> >>> fpu_exception: yes
>> >>> cpuid level: 13
>> >>> wp: yes
>> >>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
>> >>> cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
>> >>> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid 
>> >>> extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 
>> >>> sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic 
>> >>> cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt 
>> >>> lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb 
>> >>> hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale 
>> >>> vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
>> >>> bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 
>> >>> spec_store_bypass
>> >>> bogomips: 7031.92
>> >>> TLB size: 1536 4K pages
>> >>> clflush size: 64
>> >>> cache_alignment: 64
>> >>> address sizes: 48 bits physical, 48 bits virtual
>> >>> power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro
>> >>>
>> >>> Saludos
>> >>>
>> >>> El 7 de agosto de 2018, 08:25, Eduardo Visbal 
>> >>> escribió:
>> 
>>  Buenos Dias Compañero
>> 
>>  Tu verificaste si tu hardware soporta vistualizacion?
>> 
>>  ejecuta este comando y plasma aqui el resultado:
>> 
>>  egrep --color '(vmx|svm)' /proc/cpuinfo
>> 
>>  saludos
>> 
>>  Eduardo Visbal
>>  Linuxero #440451
>>  http://esdebianfritto.blogspot.com/
>> 
>> 
>>  El mar., 7 ago. 2018 a las 9:22, AFS () escribió:
>> >
>> > Buenos dias compañeros, tengo el problema que al abrir una nueva 
>> > maquina virtual el sistema se pone excesivamente lento, a la maquina 
>> > virtual solo le asigne 512 megas de RAM y aun asi el sistema se traba 
>> > y tarda en reaccionar, anteriormente tenia instalado el mismo paquete 
>> > en la misma pc y no presentaba ese problema.
>> >
>> > De los datos de mi equipo:
>> >
>> > uname -a
>> > Linux fdez 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 
>> > GNU/Linux
>> >
>> > qemu-kvm:
>> >   Installed: 1:2.12+dfsg-3
>> >
>> > virt-manager:
>> >   Installed: 1:1.5.1-1
>> >
>> > free -h
>> >   totalusedfree  shared  buff/cache   
>> > available
>> > Mem:  3.8Gi   1.5Gi   1.6Gi64Mi   721Mi
>> >2.1Gi
>> > Swap: 7.4Gi  0B   7.4Gi
>> >
>> > df -h
>> > FilesystemSize  Used Avail Use% Mounted on
>> > udev  1.9G 0  1.9G   0% /dev
>> > tmpfs 394M  6.7M  387M   2% /run
>> > /dev/sda3  92G  4.3G   83G   5% /
>> > tmpfs 2.0G   41M  1.9G   3% /dev/shm
>> > tmpfs 5.0M 0  5.0M   0% /run/lock
>> > tmpfs 2.0G 0  2.0G   0% 

Re: Asck some information for start to help Debian

[Holger Wansing]

Hi,

Ehsan Esteki  wrote:
> I never riceve the answer from my email.
> Can you give me please the feedabck.
> Thanks.
> 
> Il giorno lun 6 ago 2018 alle ore 11:43 Ehsan Esteki
>  ha scritto:
> >
> > Hello,
> > My name is Ehsan Esteki from Italy. I would like help you to translate
> > your guide and wiki in Farsi Language ( Iranian language).
> > I would like how can i start to do this for you if is possible and if
> > you need my help.
> > I wait possibly your feedback.
> > Thanks.

There is also a mailinglist specially for translation purposes:
https://lists.debian.org/debian-i18n/

And even more interesting for you, a persian l10n list:
https://lists.debian.org/debian-l10n-persian/

Otherwise, if you cannot find any suitable projects to work on:
the debian-installer would be happy to receive Farsi translation updates :-))
https://d-i.debian.org/l10n-stats/

Ask, if you have any further questions ...


Holger


-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/

Re: As seen above: use of su vs sudo

[Michael Stone]

On Tue, Aug 07, 2018 at 06:01:27PM +, Curt wrote:

I thought his point might be that in typing the full path at least you
know you're getting '/bin/su' and not some other 'su' that a malevolent
individual might have created in your home directory after prepending HOME
to your path, for example (in that malevolent person's effort to elevate
himself to superuser status).


Yes, it's just a completely useless thing to do for most plausible 
attack scenarios. Typing unnecessary characters to possibly protect 
yourself from one extremely specific (and frankly unlikely) attack seems 
more superstition than science; in a couple of decades of looking at 
compromised computers, I can't recall ever running across an attack in 
the wild that depended on someone typing "su" and not "/bin/su".


Mike Stone

Re: As seen above: use of su vs sudo

[Curt]

On 2018-08-07, Nicolas George  wrote:
>
> Curt (2018-08-07):
>> I thought his point might be that in typing the full path at least you
>> know you're getting '/bin/su' and not some other 'su' that a malevolent
>> individual might have created in your home directory after prepending HOME
>> to your path, for example (in that malevolent person's effort to elevate
>> himself to superuser status).=20
>
> Indeed. It protects you from semi-competent crackers. With incompetent
> ones, is is not needed, with competent ones it is useless. You judge if
> it is worth the hassle.

The hassle seems minimal, whereas the category of the semi-competent
appears to be fairly well-populated.

Of course, I'm a touch typist, so YMMV. 

> Regards,
>

-- 
Some years ago, when the images which this world affords first opened upon me,
when I felt the cheering warmth of summer and heard the rustling of the leaves
and the warbling of the birds, and these were all to me, I should have wept to
die; now it is my only consolation. --Mary Shelley, Frankenstein; or, The 
Modern Prometheus

Re: Installer Redmine sur Debian

[Guillaume Clercin]

Bonjour,

Le mardi 7 août 2018, 15:55:23 CEST G2PC a écrit :
> Bonjour,
> 
> J'ai ajouté une page sur mon wiki pour installer Redmine sur Debian.
> 
> En fait, j'ai installé Redmine sur GNU/Linux Mint, le titre ne
> correspond donc pas à une installation sur Debian, pour le moment.
> https://www.visionduweb.eu/wiki/index.php?title=Installer_Redmine_sur_Debian
> 
> Je ferais une installation pour Debian, par la suite.
> 
> 
> Je cherche à savoir si il est possible quand je crée le groupe redmine,
> qu'il puisse faire tourner Apache2.
> 
> Quand je crée l'utilisateur redmine, je l'ajoute dans le groupe www-data.
> 
> Ainsi, je peux affecter par la suite les fichiers à l'utilisateur et au
> groupe redmine.
> 
> Toute fois, l'utilisateur redmine est lié au groupe www-data.
> 
> Je crois qu'il doit être possible de créer l'utilisateur redmine et de
> le mettre dans le groupe redmine, mais, alors, comment faire pour que le
> groupe redmine puisse faire tourner Apache2 ?
> 
> 
> Si vous avez des informations complémentaires qui mériteraient d'être
> ajoutées sur ce tutoriel, merci de vos retours.
> 
> https://www.visionduweb.eu/wiki/index.php?title=Installer_Redmine_sur_Debian

J'ai installé passenger pour pouvoir utiliser redmine via apache. Mais je 
n'utilise pas le groupe redmine. Et je n'ai ni utilisateur ni groupe redmine.
De mémoire, j'ai changé le groupe ainsi que le propriétaire du répertoire « /
var/lib/redmine/default/files » en « www-data:www-data ».

En lisant la documentation « https://www.visionduweb.eu/wiki/index.php?
title=Installer_Redmine_sur_Debian », il est dit qu'il faut installer 
« bundler ». Je ne sais pas à quoi il sert et il n'est pas indispensable vue 
que je ne l'ai pas installé.

-- 
Guillaume Clercin

signature.asc
Description: This is a digitally signed message part.

Re: As seen above: use of su vs sudo

[Nicolas George]

Curt (2018-08-07):
> I thought his point might be that in typing the full path at least you
> know you're getting '/bin/su' and not some other 'su' that a malevolent
> individual might have created in your home directory after prepending HOME
> to your path, for example (in that malevolent person's effort to elevate
> himself to superuser status). 

Indeed. It protects you from semi-competent crackers. With incompetent
ones, is is not needed, with competent ones it is useless. You judge if
it is worth the hassle.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: As seen above: use of su vs sudo

[Curt]

On 2018-08-07, Michael Stone  wrote:
> On Tue, Aug 07, 2018 at 11:14:26AM -0500, David Wright wrote:
>>On Tue 07 Aug 2018 at 15:31:43 (+0200), Nicolas George wrote:
>>> The Wanderer (2018-08-07):
>>
>>> > > Anyone who learns the user's password can obtain the second password
>>> > > pretty easily.
>>> > How so?
>>>
>>> Just insert a fake su in their path. There are more subtle ways.
>>
>>This does make me wonder why nobody here seems to have pointed out
>>that su should be spelled "/bin/su -". My fingers have been wired
>>that way for 20 years.
>
> Because it's unnecessary extra typing?
>

I thought his point might be that in typing the full path at least you
know you're getting '/bin/su' and not some other 'su' that a malevolent
individual might have created in your home directory after prepending HOME
to your path, for example (in that malevolent person's effort to elevate
himself to superuser status). 

Maybe he didn't mean that, though, and I've got things all wrong (famous
last words).



-- 
Some years ago, when the images which this world affords first opened upon me,
when I felt the cheering warmth of summer and heard the rustling of the leaves
and the warbling of the birds, and these were all to me, I should have wept to
die; now it is my only consolation. --Mary Shelley, Frankenstein; or, The 
Modern Prometheus

Re: Indicador de volumen en XFCE4

[Juan]

El 07/08/2018 a las 13:16, Marcelo Eduardo Giordano escribió:



El 03/08/18 a las 12:45, Marcelo P. Llanos C. escribió:

ejecuta pavucontrol desde terminal:


$ pavucontrol

El 1 de agosto de 2018, 23:32, rv riveravaldez 
mailto:riveravaldezm...@gmail.com>> escribió:


2018-07-31 17:19 GMT-03:00 Julian Daich mailto:julia...@gmail.com>>:
> Hola,
>
> No me aparece el indicador de volumen en Sid¿ como hago para que
esté
> en el área de notificaciones?
>
> Saludos,
>
> Julián
>
> --
> Julian
>

Por si acaso prueba 'alsamixer' (sin comillas) en una terminal, a ver
si el audio funciona bien.

Luego en XFCE creo recordar que el indicador de volumen era un plugin
(o como lo quieras llamar) del panel inferior: búscalo con
click-derecho entre las opciones que salen en el menú.

Saludos



Gracias por el dato. Instalé el plugin (o como lo quieras llamar). Muy útil


Buenas tardes, yo hacía mucho que lo tenía como pendiente de resolver, 
como el teclado me deja subir y bajar el volumen, no le di mucha 
importancia, pero ayer cuando vi el correo de divagante, seguí esos 
pasos y lo resolví.
No me cambia la vida, pero era algo que cada tanto recordaba que faltaba 
y siempre tenia algo mas urgente que hacer y lo dejaba.

Gracias

[solved?] Re: New `no sound' problems

[Rodolfo Medina]

Rodolfo Medina  writes:

> It seems to be damned recursive, the problem...  After yesterday's
> full-upgrade in Sid, my old Acer One without sound once again...  Everything
> seems all right: alsamixer, aumix, pulseaudio installed...  Last time this
> happened, it was solved installing pulseaudio and alsaplayer-alsa...  Now it
> won't...  Please help.

I `aptitude purge-d' pulseaudio and... (after maybe reboot) sound back again...

Rodolfo

Re: need help with sftp

[Greg Wooledge]

On Tue, Aug 07, 2018 at 09:53:57AM -0700, Fred wrote:
> On a new Sid installation I need to ftp some files to another computer on
> the network.  sftp appears to be the only ftp program available.  The other
> computers on the network do not use ssl so the ftp connection is refused
> from both directions.  One computer is using vsftp under Jessie.  I don't
> see any option that makes sftp just do plain ordinary ftp.  Is this
> hopeless?

https://mywiki.wooledge.org/FtpMustDie

SFTP and FTP are completely different protocols.  They have nothing in
common except 3 letters in their names.

SFTP is implemented on the server side by sshd.  You connect with an SFTP
client (e.g. the sftp command, or an sshfs mounted file system) using
the same credentials that you would use for a regular ssh session.  SFTP
is encrypted, it can be tunnelled through a firewall, etc.

FTP has none of those features.

If you actually *need* to use FTP for some reason (legacy systems on the
network), note first that Debian does NOT install an FTP server package
by default, but it offers several of them.  You can choose one, and
install it, and then you will be able to make FTP connections to your
Debian system.  Authentication will be done using whatever your chosen
FTP server package uses.  Traffic will be unencrypted, and will fly
around in random directions depending on which mode you use, and everything
will fall apart when there are firewalls between client and server.

If you think that you need FTP because of Microsoft Windows systems,
please note that there are many user-friendly graphical SFTP clients
for Microsoft Windows.  You are probably not restricted to its built-in
FTP client.

Re: need help with sftp

[john doe]

On 8/7/2018 6:53 PM, Fred wrote:

Hi,

On a new Sid installation I need to ftp some files to another computer 
on the network.  sftp appears to be the only ftp program available.  The 
other computers on the network do not use ssl so the ftp connection is 
refused from both directions.  One computer is using vsftp under 
Jessie.  I don't see any option that makes sftp just do plain ordinary 
ftp.  Is this hopeless?




To use sftp you need to have ssh setup between the client and the server.

Basically, it will only work if both the client and server are using the 
same protocol.


What protocol(s) do you have available on the client and the server?

--
John Doe

Re: need help with sftp

[Roberto C . Sánchez]

On Tue, Aug 07, 2018 at 09:53:57AM -0700, Fred wrote:
> Hi,
> 
> On a new Sid installation I need to ftp some files to another computer on
> the network.  sftp appears to be the only ftp program available.  The other
> computers on the network do not use ssl so the ftp connection is refused
> from both directions.  One computer is using vsftp under Jessie.  I don't
> see any option that makes sftp just do plain ordinary ftp.  Is this
> hopeless?
> 
sftp != ftp != ftps

sftp - "secure" ftp (i.e., implementation of FTP-like protocol, that is
not actually FTP, over SSH transport)

ftp - "traditional" file transfer protocol

ftps - FTP with SSL (very rarely used)

If the server in question is running vsftpd, then you want to use a
client like lftp or inetutils-ftp or similar.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: As seen above: use of su vs sudo

[Michael Stone]

On Tue, Aug 07, 2018 at 11:14:26AM -0500, David Wright wrote:

On Tue 07 Aug 2018 at 15:31:43 (+0200), Nicolas George wrote:

The Wanderer (2018-08-07):



> > Anyone who learns the user's password can obtain the second password
> > pretty easily.
> How so?

Just insert a fake su in their path. There are more subtle ways.


This does make me wonder why nobody here seems to have pointed out
that su should be spelled "/bin/su -". My fingers have been wired
that way for 20 years.


Because it's unnecessary extra typing?

need help with sftp

[Fred]

Hi,

On a new Sid installation I need to ftp some files to another computer 
on the network.  sftp appears to be the only ftp program available.  The 
other computers on the network do not use ssl so the ftp connection is 
refused from both directions.  One computer is using vsftp under 
Jessie.  I don't see any option that makes sftp just do plain ordinary 
ftp.  Is this hopeless?


Best regards,
Fred

Re: Please help with error message

[Rodolfo Medina]

deloptes  writes:

> Rodolfo Medina wrote:
>
>> Yes, if becoming root with with `su -' the error about what is the present
>> thread disappears...
>
> I guess sudo is always better to use


I'd always thought that `su' was Debian's and `sudo' was Ubuntu's...  :-)

Rodolfo

Re: As seen above: use of su vs sudo

[Greg Wooledge]

On Tue, Aug 07, 2018 at 06:29:58PM +0200, Nicolas George wrote:
> David Wright (2018-08-07):
> > This does make me wonder why nobody here seems to have pointed out
> > that su should be spelled "/bin/su -". My fingers have been wired
> > that way for 20 years.
> 
> As I said, there are more subtle ways, and the full path will not
> protect you from them.

wooledg:~$ function /bin/su { echo haha; }
wooledg:~$ /bin/su root
haha

Just one of many ways a malicious user can compromise the interactive
environment.  An even better one is to run a key logger, to capture the
root password when you type it in their X session.

Re: As seen above: use of su vs sudo

[Nicolas George]

David Wright (2018-08-07):
> This does make me wonder why nobody here seems to have pointed out
> that su should be spelled "/bin/su -". My fingers have been wired
> that way for 20 years.

As I said, there are more subtle ways, and the full path will not
protect you from them.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: As seen above: use of su vs sudo

[mick crane]

I think as a general philosophy it used to be
this is your computer, as user we make sure it works and you can do some 
things.

You can also be root but if you break it you get to keep the bits.

mick



--
Key ID4BFEBB31

Re: comment récupérer altgr au clavier

[Bernard Schoenacker]

- Mail original -
> De: "Alexandre Hoïde" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mardi 7 Août 2018 16:46:10
> Objet: Re: comment récupérer altgr au clavier
> 
> On Tue, Aug 07, 2018 at 04:02:50PM +0200, Bernard Schoenacker wrote:
> > - Mail original -
> > > Peut-être pourrais-tu essayer également en console avec
> > > $ showkey' (du paquet « kbd ») ?
> > > 
> > merci pour le coup de pouce, mais j'ai aucun signal pour altgr sur
> > le clavier principal ( touche 100) et j'ai pu obtenir le signal sur
> > un clavier auxiliaire usb
> > 
> > merci pour tout
> 
>   Je t'en prie ! Mais… essayes quand même en console avec
> '$ showkey -s' car je suis [presque] certain que le noyau donnera le
> « scancode » de la touche, même si le clavier est mal configuré. J'en
> suis moins sûr pour '$ xev'.
> 
>   Ca te permettrait de savoir avec [une quasi^^] certitude si le
> problème est matériel ou logiciel.
> 
>   Et si c'est matériel, tout espoir n'est peut-être pas perdu
>   (essayer
> de nettoyer, souffler, …).

bonjour,

j'ai réessayé avec la commande showkey -s et je n'ai pas de signal
le clavier est cuit ...

merci
slt
bernard

Re: As seen above: use of su vs sudo

[Joe Pfeiffer]

Martin  writes:

> [...]
>>>
>>> is new to me, I never knew! And I think it is good approach.
>>> Does one actually get pointed to this during install?
>> 
>>   ┌───┤ [?] Set up users and passwords 
>> ├┐   
>>   │  
>>│   
>>   │ If you choose not to allow root to log in, then a user account will 
>> be  │   
>>   │ created and given the power to become root using the 'sudo' command. 
>>│   
>>   │  
>>│   
>>   │ Allow login as root? 
>>│   
>>   │  
>>│   
>>   │
>>│   
>>   │  
>>│   
>>   
>> └─┘  
>>  
>> 
>> Cheers,
>> David.
>> 
>
> How cool is that :-)
> Actually, I mostly use the graphical installer for manual install. I
> just checked: This dialogue is 10 lines long. I usually stooped
> reading after "You need do set a password for 'root'...".

Though it seems like installing sudo and asking whether the "first user"
should be in sudoers would be a better thing to do even if root can log
in.

Re: Indicador de volumen en XFCE4

[Marcelo Eduardo Giordano]

El 03/08/18 a las 12:45, Marcelo P. Llanos C. escribió:

ejecuta pavucontrol desde terminal:


$ pavucontrol

El 1 de agosto de 2018, 23:32, rv riveravaldez 
mailto:riveravaldezm...@gmail.com>> escribió:


2018-07-31 17:19 GMT-03:00 Julian Daich mailto:julia...@gmail.com>>:
> Hola,
>
> No me aparece el indicador de volumen en Sid¿ como hago para que
esté
> en el área de notificaciones?
>
> Saludos,
>
> Julián
>
> --
> Julian
>

Por si acaso prueba 'alsamixer' (sin comillas) en una terminal, a ver
si el audio funciona bien.

Luego en XFCE creo recordar que el indicador de volumen era un plugin
(o como lo quieras llamar) del panel inferior: búscalo con
click-derecho entre las opciones que salen en el menú.

Saludos



Gracias por el dato. Instalé el plugin (o como lo quieras llamar). Muy útil

Re: As seen above: use of su vs sudo

[David Wright]

On Tue 07 Aug 2018 at 15:31:43 (+0200), Nicolas George wrote:
> The Wanderer (2018-08-07):

> > > Anyone who learns the user's password can obtain the second password 
> > > pretty easily.
> > How so?
> 
> Just insert a fake su in their path. There are more subtle ways.

This does make me wonder why nobody here seems to have pointed out
that su should be spelled "/bin/su -". My fingers have been wired
that way for 20 years.

Cheers,
David.

Re: As seen above: use of su vs sudo

[David Wright]

On Tue 07 Aug 2018 at 08:07:56 (-0400), The Wanderer wrote:

> I'm fairly sure that when I did (some of) my existing installs - which,
> to be fair, was years and years ago - sudo came with the system, even
> though I didn't even consider the concept of setting the machine up with
> no root password. Maybe this has changed at some point.

sudo was optional even in buzz (1.1):

Package: sudo
priority: optional
section: admin
maintainer: Michael Meskes 
version: 1.4.2-2

AFAICT No Root Password arrived with wheezy (7).

Cheers,
David.

Re: Problema con kvm-qemu

[AFS]

Que tal Felix,  efectivamente intente subirle la RAM pero el sistema se
vuelve mas inestable, cuando me refiero al sistema me refiero a mi PC
Fisica, no a la virtual.

Saludos.

El 7 de agosto de 2018, 09:23, Felix Perez
escribió:

> El mar., 7 de ago. de 2018 a la(s) 09:53, AFS (abe...@gmail.com) escribió:
> >
> > Gracias por contestar Eduardo.  Revisando el log no hay nada raro y
> acabo de instalar el sistema, no he actualizado nada.
> >
>
> Hola, probaste ampliando la mem asignada a la VM? Me paso con
> virtualbox en una oportunidad que si le asignaba poca RAM al sistema
> virtualizado, el sistema principal se arrastraba, si le aumentaba la
> ram se normalizaba.  No te puedo aportar mayores antecedentes ya que
> era en una maquina de pruebas y no le dí mayor importancia y además no
> me sucedió nunca más.
>
> Suerte.
>
>
> > Saludos
> >
> > El 7 de agosto de 2018, 08:37, Eduardo Visbal
> escribió:
> >>
> >> Los Log del sistema te muestran algo fuera de lo normal?
> >> Esta lentitud fue a raíz de alguna actualización del sistema?
> >>
> >> Eduardo Visbal
> >> Linuxero #440451
> >> http://esdebianfritto.blogspot.com/
> >>
> >>
> >> El mar., 7 ago. 2018 a las 9:30, AFS () escribió:
> >>>
> >>> Si soporta Virtualizacion.
> >>>
> >>> cat /proc/cpuinfo
> >>> processor: 0
> >>> vendor_id: AuthenticAMD
> >>> cpu family: 21
> >>> model: 2
> >>> model name: AMD FX(tm)-6300 Six-Core Processor
> >>> stepping: 0
> >>> microcode: 0x600081c
> >>> cpu MHz: 1793.726
> >>> cache size: 2048 KB
> >>> physical id: 0
> >>> siblings: 6
> >>> core id: 0
> >>> cpu cores: 3
> >>> apicid: 16
> >>> initial apicid: 0
> >>> fpu: yes
> >>> fpu_exception: yes
> >>> cpuid level: 13
> >>> wp: yes
> >>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid
> aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes
> xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
> misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr
> tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat
> npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists
> pausefilter pfthreshold
> >>> bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1
> spectre_v2 spec_store_bypass
> >>> bogomips: 7031.92
> >>> TLB size: 1536 4K pages
> >>> clflush size: 64
> >>> cache_alignment: 64
> >>> address sizes: 48 bits physical, 48 bits virtual
> >>> power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro
> >>>
> >>> Saludos
> >>>
> >>> El 7 de agosto de 2018, 08:25, Eduardo Visbal
> escribió:
> 
>  Buenos Dias Compañero
> 
>  Tu verificaste si tu hardware soporta vistualizacion?
> 
>  ejecuta este comando y plasma aqui el resultado:
> 
>  egrep --color '(vmx|svm)' /proc/cpuinfo
> 
>  saludos
> 
>  Eduardo Visbal
>  Linuxero #440451
>  http://esdebianfritto.blogspot.com/
> 
> 
>  El mar., 7 ago. 2018 a las 9:22, AFS () escribió:
> >
> > Buenos dias compañeros, tengo el problema que al abrir una nueva
> maquina virtual el sistema se pone excesivamente lento, a la maquina
> virtual solo le asigne 512 megas de RAM y aun asi el sistema se traba y
> tarda en reaccionar, anteriormente tenia instalado el mismo paquete en la
> misma pc y no presentaba ese problema.
> >
> > De los datos de mi equipo:
> >
> > uname -a
> > Linux fdez 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64
> GNU/Linux
> >
> > qemu-kvm:
> >   Installed: 1:2.12+dfsg-3
> >
> > virt-manager:
> >   Installed: 1:1.5.1-1
> >
> > free -h
> >   totalusedfree  shared  buff/cache
>  available
> > Mem:  3.8Gi   1.5Gi   1.6Gi64Mi   721Mi
>  2.1Gi
> > Swap: 7.4Gi  0B   7.4Gi
> >
> > df -h
> > FilesystemSize  Used Avail Use% Mounted on
> > udev  1.9G 0  1.9G   0% /dev
> > tmpfs 394M  6.7M  387M   2% /run
> > /dev/sda3  92G  4.3G   83G   5% /
> > tmpfs 2.0G   41M  1.9G   3% /dev/shm
> > tmpfs 5.0M 0  5.0M   0% /run/lock
> > tmpfs 2.0G 0  2.0G   0% /sys/fs/cgroup
> > /dev/sda1 735M   47M  635M   7% /boot
> > /dev/mapper/afs-home  1.9T  9.2G  1.8T   1% /home
> > /dev/mapper/afs-var   458G   41G  394G  10% /var
> > tmpfs 394M   16K  394M   1% /run/user/115
> > tmpfs 394M  3.5M  390M   1% /run/user/1000
> >
> > Gracias por su atención.
> >>>
> >>>
> >
>
>
> --
> usuario linux  #274354
> normas de 

Re: As seen above: use of su vs sudo

[Martin]

[...]
>>
>> is new to me, I never knew! And I think it is good approach.
>> Does one actually get pointed to this during install?
> 
>   ┌───┤ [?] Set up users and passwords 
> ├┐   
>   │   
>   │   
>   │ If you choose not to allow root to log in, then a user account will 
> be  │   
>   │ created and given the power to become root using the 'sudo' command.  
>   │   
>   │   
>   │   
>   │ Allow login as root?  
>   │   
>   │   
>   │   
>   │ 
>   │   
>   │   
>   │   
>   
> └─┘   
> 
> 
> Cheers,
> David.
> 

How cool is that :-)
Actually, I mostly use the graphical installer for manual install. I just 
checked: This dialogue is 10 lines long. I usually stooped reading after "You 
need do set a password for 'root'...".


Cheers to you!

Re: As seen above: use of su vs sudo

[David Wright]

On Tue 07 Aug 2018 at 13:23:06 (+0200), Martin Drescher wrote:
> That
> 
> > If you set a root password in d-i (as it asks you to), it doesn't
> > install sudo. If you try to set a blank root password, it locks the root
> > account, installs sudo and sets up the user you created with sudo
> > access.
> 
> is new to me, I never knew! And I think it is good approach.
> Does one actually get pointed to this during install?

  ┌───┤ [?] Set up users and passwords 
├┐   
  │ 
│   
  │ If you choose not to allow root to log in, then a user account will be  
│   
  │ created and given the power to become root using the 'sudo' command.
│   
  │ 
│   
  │ Allow login as root?
│   
  │ 
│   
  │   
│   
  │ 
│   
  
└─┘ 
  

Cheers,
David.

Re: comment récupérer altgr au clavier

[Alexandre Hoïde]

On Tue, Aug 07, 2018 at 04:02:50PM +0200, Bernard Schoenacker wrote:
> - Mail original -
> > Peut-être pourrais-tu essayer également en console avec 
> > $ showkey' (du paquet « kbd ») ?
> > 
> merci pour le coup de pouce, mais j'ai aucun signal pour altgr sur 
> le clavier principal ( touche 100) et j'ai pu obtenir le signal sur
> un clavier auxiliaire usb
> 
> merci pour tout

  Je t'en prie ! Mais… essayes quand même en console avec
'$ showkey -s' car je suis [presque] certain que le noyau donnera le
« scancode » de la touche, même si le clavier est mal configuré. J'en
suis moins sûr pour '$ xev'.

  Ca te permettrait de savoir avec [une quasi^^] certitude si le
problème est matériel ou logiciel.

  Et si c'est matériel, tout espoir n'est peut-être pas perdu (essayer
de nettoyer, souffler, …).

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: Problema con kvm-qemu

[Felix Perez]

El mar., 7 de ago. de 2018 a la(s) 09:53, AFS (abe...@gmail.com) escribió:
>
> Gracias por contestar Eduardo.  Revisando el log no hay nada raro y acabo de 
> instalar el sistema, no he actualizado nada.
>

Hola, probaste ampliando la mem asignada a la VM? Me paso con
virtualbox en una oportunidad que si le asignaba poca RAM al sistema
virtualizado, el sistema principal se arrastraba, si le aumentaba la
ram se normalizaba.  No te puedo aportar mayores antecedentes ya que
era en una maquina de pruebas y no le dí mayor importancia y además no
me sucedió nunca más.

Suerte.


> Saludos
>
> El 7 de agosto de 2018, 08:37, Eduardo Visbal 
> escribió:
>>
>> Los Log del sistema te muestran algo fuera de lo normal?
>> Esta lentitud fue a raíz de alguna actualización del sistema?
>>
>> Eduardo Visbal
>> Linuxero #440451
>> http://esdebianfritto.blogspot.com/
>>
>>
>> El mar., 7 ago. 2018 a las 9:30, AFS () escribió:
>>>
>>> Si soporta Virtualizacion.
>>>
>>> cat /proc/cpuinfo
>>> processor: 0
>>> vendor_id: AuthenticAMD
>>> cpu family: 21
>>> model: 2
>>> model name: AMD FX(tm)-6300 Six-Core Processor
>>> stepping: 0
>>> microcode: 0x600081c
>>> cpu MHz: 1793.726
>>> cache size: 2048 KB
>>> physical id: 0
>>> siblings: 6
>>> core id: 0
>>> cpu cores: 3
>>> apicid: 16
>>> initial apicid: 0
>>> fpu: yes
>>> fpu_exception: yes
>>> cpuid level: 13
>>> wp: yes
>>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
>>> cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
>>> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid 
>>> aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes 
>>> xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
>>> misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr 
>>> tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat 
>>> npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists 
>>> pausefilter pfthreshold
>>> bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 
>>> spec_store_bypass
>>> bogomips: 7031.92
>>> TLB size: 1536 4K pages
>>> clflush size: 64
>>> cache_alignment: 64
>>> address sizes: 48 bits physical, 48 bits virtual
>>> power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro
>>>
>>> Saludos
>>>
>>> El 7 de agosto de 2018, 08:25, Eduardo Visbal 
>>> escribió:

 Buenos Dias Compañero

 Tu verificaste si tu hardware soporta vistualizacion?

 ejecuta este comando y plasma aqui el resultado:

 egrep --color '(vmx|svm)' /proc/cpuinfo

 saludos

 Eduardo Visbal
 Linuxero #440451
 http://esdebianfritto.blogspot.com/


 El mar., 7 ago. 2018 a las 9:22, AFS () escribió:
>
> Buenos dias compañeros, tengo el problema que al abrir una nueva maquina 
> virtual el sistema se pone excesivamente lento, a la maquina virtual solo 
> le asigne 512 megas de RAM y aun asi el sistema se traba y tarda en 
> reaccionar, anteriormente tenia instalado el mismo paquete en la misma pc 
> y no presentaba ese problema.
>
> De los datos de mi equipo:
>
> uname -a
> Linux fdez 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 
> GNU/Linux
>
> qemu-kvm:
>   Installed: 1:2.12+dfsg-3
>
> virt-manager:
>   Installed: 1:1.5.1-1
>
> free -h
>   totalusedfree  shared  buff/cache   
> available
> Mem:  3.8Gi   1.5Gi   1.6Gi64Mi   721Mi   
> 2.1Gi
> Swap: 7.4Gi  0B   7.4Gi
>
> df -h
> FilesystemSize  Used Avail Use% Mounted on
> udev  1.9G 0  1.9G   0% /dev
> tmpfs 394M  6.7M  387M   2% /run
> /dev/sda3  92G  4.3G   83G   5% /
> tmpfs 2.0G   41M  1.9G   3% /dev/shm
> tmpfs 5.0M 0  5.0M   0% /run/lock
> tmpfs 2.0G 0  2.0G   0% /sys/fs/cgroup
> /dev/sda1 735M   47M  635M   7% /boot
> /dev/mapper/afs-home  1.9T  9.2G  1.8T   1% /home
> /dev/mapper/afs-var   458G   41G  394G  10% /var
> tmpfs 394M   16K  394M   1% /run/user/115
> tmpfs 394M  3.5M  390M   1% /run/user/1000
>
> Gracias por su atención.
>>>
>>>
>


-- 
usuario linux  #274354
normas de la lista:  http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html

Re: As seen above: use of su vs sudo

[Stephan Seitz]

On Di, Aug 07, 2018 at 02:27:48 +0200, Martin wrote:
Come on. You are telling me, it is more secure to share one secret among 
multiple people against every person having it own?


If the password is stored in a password safe, and everyone in the IT has 
access to it, where is the problem?


First you have to log in to a user's account. And I'm quite sure, you 
will use ssh with keys that, right?


I do it (at least in most cases, my key is not on every system I may need 
to login). Others don’t, they use their LDAP password.


Yes, this is way more complex than su. But it will improve system 
security by far, when in good hands.


If this security isn’t needed why bother?

Shade and sweet water!

Stephan

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


smime.p7s
Description: S/MIME cryptographic signature

Re: comment récupérer altgr au clavier

[Bernard Schoenacker]

- Mail original -
> De: "Alexandre Hoïde" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mardi 7 Août 2018 15:47:45
> Objet: Re: comment récupérer altgr au clavier
> 
> On Tue, Aug 07, 2018 at 03:09:15PM +0200, Bernard Schoenacker wrote:
> > 
> > 
> > - Mail original -
> > > De: "Alexandre Hoïde" 
> > >   Oui, c'est certainement gonflant ! Mais commence par voir si '$
> > >   xev' détecte le AltGr du clavier intégré.
> > j'ai essayé xev et je n'ai aucun signal sur altgr ...
> > 
> > j'ai l'impression que le clavier est hs
> 
>   Possible… mais j'ignore si un mauvais choix de type de clavier
> pourrait rendre la touche invisible à 'xev' (auquel cas, ce ne serait
> pas forcément une défaillance matérielle). Peut-être pourrais-tu
> essayer également en console avec '$ showkey' (du paquet « kbd ») ?
> 
bonjour,

merci pour le coup de pouce, mais j'ai aucun signal pour altgr sur 
le clavier principal ( touche 100) et j'ai pu obtenir le signal sur
un clavier auxiliaire usb

merci pour tout

slt
bernard

Re: As seen above: use of su vs sudo

[mick crane]

On 2018-08-07 10:58, Martin Drescher wrote:

Hi members,

I'm a little... lets say thoughtful, about the use of 'su' discussed
at some points in this list.
I have a strong opinion about su, which is, avoid it whenever it is
possible and use 'sudo' instead. This is the case in close to a 100%
in all cases I can think of.
This opinion is based on how both programs work and deal with pam and
environmental variables. Not to forget: You will not need to share (or
in my case, not even set, but lock that account) a root password.

And I'm curious why Debian still prefers the use of su over sudo?


Martin.
I'm probably the average home user with a couple of servers and an 
interest.
Early on I did type "rm -rf ./*" as root when at that time su put you in 
"/"


I use[d] su to change file permissions and ownership on files in a 
directory for apache and for "make install" on the rare occasions I 
compile something from source and that's about it.
Was updating Brave browser the other day and ran into this "can't find 
ldconfig"

So now I know what's happened I'm cheerful enough.
mick
--
Key ID4BFEBB31

Installer Redmine sur Debian

[G2PC]

Bonjour,

J'ai ajouté une page sur mon wiki pour installer Redmine sur Debian.

En fait, j'ai installé Redmine sur GNU/Linux Mint, le titre ne
correspond donc pas à une installation sur Debian, pour le moment.
https://www.visionduweb.eu/wiki/index.php?title=Installer_Redmine_sur_Debian

Je ferais une installation pour Debian, par la suite.


Je cherche à savoir si il est possible quand je crée le groupe redmine,
qu'il puisse faire tourner Apache2.

Quand je crée l'utilisateur redmine, je l'ajoute dans le groupe www-data.

Ainsi, je peux affecter par la suite les fichiers à l'utilisateur et au
groupe redmine.

Toute fois, l'utilisateur redmine est lié au groupe www-data.

Je crois qu'il doit être possible de créer l'utilisateur redmine et de
le mettre dans le groupe redmine, mais, alors, comment faire pour que le
groupe redmine puisse faire tourner Apache2 ?


Si vous avez des informations complémentaires qui mériteraient d'être
ajoutées sur ce tutoriel, merci de vos retours.

https://www.visionduweb.eu/wiki/index.php?title=Installer_Redmine_sur_Debian

Re: Problema con kvm-qemu

[AFS]

Gracias por contestar Eduardo.  Revisando el log no hay nada raro y acabo
de instalar el sistema, no he actualizado nada.

Saludos

El 7 de agosto de 2018, 08:37, Eduardo Visbal
escribió:

> Los Log del sistema te muestran algo fuera de lo normal?
> Esta lentitud fue a raíz de alguna actualización del sistema?
>
>
>
> *Eduardo VisbalLinuxero #440451http://esdebianfritto.blogspot.com/
> *
>
>
> El mar., 7 ago. 2018 a las 9:30, AFS () escribió:
>
>> Si soporta Virtualizacion.
>>
>> cat /proc/cpuinfo
>> processor: 0
>> vendor_id: AuthenticAMD
>> cpu family: 21
>> model: 2
>> model name: AMD FX(tm)-6300 Six-Core Processor
>> stepping: 0
>> microcode: 0x600081c
>> cpu MHz: 1793.726
>> cache size: 2048 KB
>> physical id: 0
>> siblings: 6
>> core id: 0
>> cpu cores: 3
>> apicid: 16
>> initial apicid: 0
>> fpu: yes
>> fpu_exception: yes
>> cpuid level: 13
>> wp: yes
>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
>> cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
>> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid
>> aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes
>> xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
>> misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr
>> tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat
>> npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists
>> pausefilter pfthreshold
>> bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2
>> spec_store_bypass
>> bogomips: 7031.92
>> TLB size: 1536 4K pages
>> clflush size: 64
>> cache_alignment: 64
>> address sizes: 48 bits physical, 48 bits virtual
>> power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro
>>
>> Saludos
>>
>> El 7 de agosto de 2018, 08:25, Eduardo Visbal
>> escribió:
>>
>>> Buenos Dias Compañero
>>>
>>> Tu verificaste si tu hardware soporta vistualizacion?
>>>
>>> ejecuta este comando y plasma aqui el resultado:
>>>
>>> *egrep --color '(vmx|svm)' /proc/cpuinfo*
>>>
>>>
>>> *saludos*
>>>
>>>
>>>
>>> *Eduardo VisbalLinuxero #440451http://esdebianfritto.blogspot.com/
>>> *
>>>
>>>
>>> El mar., 7 ago. 2018 a las 9:22, AFS () escribió:
>>>
 Buenos dias compañeros, tengo el problema que al abrir una nueva
 maquina virtual el sistema se pone excesivamente lento, a la maquina
 virtual solo le asigne 512 megas de RAM y aun asi el sistema se traba y
 tarda en reaccionar, anteriormente tenia instalado el mismo paquete en la
 misma pc y no presentaba ese problema.

 De los datos de mi equipo:

 uname -a
 Linux fdez 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64
 GNU/Linux

 qemu-kvm:
   Installed: 1:2.12+dfsg-3

 virt-manager:
   Installed: 1:1.5.1-1

 free -h
   totalusedfree  shared  buff/cache
 available
 Mem:  3.8Gi   1.5Gi   1.6Gi64Mi
 721Mi   2.1Gi
 Swap: 7.4Gi  0B   7.4Gi

 df -h
 FilesystemSize  Used Avail Use% Mounted on
 udev  1.9G 0  1.9G   0% /dev
 tmpfs 394M  6.7M  387M   2% /run
 /dev/sda3  92G  4.3G   83G   5% /
 tmpfs 2.0G   41M  1.9G   3% /dev/shm
 tmpfs 5.0M 0  5.0M   0% /run/lock
 tmpfs 2.0G 0  2.0G   0% /sys/fs/cgroup
 /dev/sda1 735M   47M  635M   7% /boot
 /dev/mapper/afs-home  1.9T  9.2G  1.8T   1% /home
 /dev/mapper/afs-var   458G   41G  394G  10% /var
 tmpfs 394M   16K  394M   1% /run/user/115
 tmpfs 394M  3.5M  390M   1% /run/user/1000

 Gracias por su atención.

>>>
>>

Re: As seen above: use of su vs sudo

[Martin]

>> Once you let a user run an editor with escalated privileges, you're
>> fu**ed. In almost every editor, you can load a different file, save
>> the buffer with a different file name.
> 
> Of course.
> 
> Again, that comes down to: do you trust this user with elevated access,
> or not?


It is not about trust. It is about authorisation. About privileges and how to 
control them effectively.
You may trust your friend not to crash your shiny new car. But would you just 
give the key and let go?

Re: comment récupérer altgr au clavier

[Alexandre Hoïde]

On Tue, Aug 07, 2018 at 03:09:15PM +0200, Bernard Schoenacker wrote:
> 
> 
> - Mail original -
> > De: "Alexandre Hoïde" 
> >   Oui, c'est certainement gonflant ! Mais commence par voir si '$
> >   xev' détecte le AltGr du clavier intégré.
> j'ai essayé xev et je n'ai aucun signal sur altgr ...
> 
> j'ai l'impression que le clavier est hs

  Possible… mais j'ignore si un mauvais choix de type de clavier
pourrait rendre la touche invisible à 'xev' (auquel cas, ce ne serait
pas forcément une défaillance matérielle). Peut-être pourrais-tu
essayer également en console avec '$ showkey' (du paquet « kbd ») ?

-- 
 ___
| $ post_tenebras ↲ | waouh!
| GNU\ /|\
|  -- * --  | o
| $ who ↲/ \|_-- ~_|
| Alexandre Hoïde   |  _/| |
 ---

Re: As seen above: use of su vs sudo

[Michael Stone]

On Tue, Aug 07, 2018 at 09:22:07AM -0400, The Wanderer wrote:

Or, rather, that you can do elevated-access things with the same
credentials as are used to permit non-elevated access.

I consider that to be, by definition, a security hole.


That can be addressed three ways: first, you can have sudo require the 
root password instead of the user password; second, you can use pam to 
have sudo require different credentials than the login password; third, 
you can use pam to have sudo require multi-factor authentication. The 
configuration that makes the most sense depends heavily on the local 
environment. I'd personally consider a well-implemented multi-factor 
scheme to be much more secure (and easier to manage) than discrete 
root passwords, and much easier to implement safely (including emergency 
access) using sudo rather than su. I tend to agree that just replacing 
su with sudo doesn't buy much security and may be a net negative if done 
carelessly; to really get value from sudo requires a good bit of 
customization--and it's hard to see a return on that work in a small 
environment. If the security factors are the same and the workflow is 
functionally identical except that instead of "su -" someone uses "sudo 
-s" or prefixes every command with sudo, it seems clearly a matter of 
preference and muscle memory rather than substance.


Mike Stone

Re: As seen above: use of su vs sudo

[Martin]

> I've long forgotten why, but I committed "sudo su -" to muscle memory

First, you execute sudo with target UID 0 (aka. root). 
While doing that, sudo does all the fancy things for you, like setting or 
unsetting environments (eg SUDO_COMMAND, SUDO_UID, SUDO_USER) and check, if you 
will be granted to run $ANY_COMMAND or may be /bin/su with that target UID 0.
Next, with UID 0, you run /bin/su in order, to gain a login shell. Now '/bin/su 
-' runs the login process stripping all the things set before off. Just to run 
/bin/sh at the end.

You could have run 'sudo -c /bin/sh'.
In reality, 'sudo -i [-u TARGET_USER]' is your friend. Always.

Re: As seen above: use of su vs sudo

[Nicolas George]

The Wanderer (2018-08-07):
> I don't consider that a significant downside;

Maybe your uses are too limited for you to experience it.

>   in some contexts, it may
> even be an advantage.

No, it may not. With sudo, adding "sh -c" allows to emulate su's
behaviour. On the other hand, su cannot emulate sudo's behaviour at all.

> An inclination in the direction of doing that would be a mark against
> that user being considered sufficiently trustworthy to have the elevated
> access to begin with.

I was referring to the real world, not wishful thinking.

> > Anyone who learns the user's password can obtain the second password 
> > pretty easily.
> How so?

Just insert a fake su in their path. There are more subtle ways.

> There's a point there, but I do consider the rest of the system (beyond
> just the user's account) to be something worth securing, even on a
> single-user system.

Maybe. But it does not need to be *more* secure than the user's account.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: As seen above: use of su vs sudo

[The Wanderer]

On 2018-08-07 at 09:22, Dave Sherohman wrote:

> On Tue, Aug 07, 2018 at 08:07:56AM -0400, The Wanderer wrote:
> 
>> On 2018-08-07 at 07:47, Martin wrote:
>> 
>>> The point is not, that ONE person needs a root password. All
>>> people intended to do privileged things will have to share this
>>> password. This is a security nightmare!
>> 
>> If they're all trusted enough to be trusted with that password in
>> the first place, this isn't a problem, any more than the one person
>> having it is.
>> 
>> If they aren't trusted enough to have that password, why are we 
>> permitting them to do anything root-level in the first place?
> 
> It's not just a question of trust, but also one of maintenance.
> What happens when one of the people with root access gets a new job?
> 
> Using su and a shared root password:
> - Disable the person's account.
> - Change the root password.
> - Find a secure way to distribute the new password to all the people
>   it's shared by.
> 
> Using sudo:
> - Disable the person's account.
> - Remove the account from /etc/sudoers and/or the sudo group.
> 
> Everyone else with root access is completely unaffected by the
> departure.

That's a valid point.

I'm not sure it's enough to outweigh the other factors underlying my
opinion on the subject (especially not since the computers I'm working
with in the cases at hand aren't work machines, they're home systems,
and the "other users" are either family members or close friends -
although I'll admit the scope of the discussion is broader than that),
but it's definitely an important consideration, and there are contexts
in which it could trump.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Problema con kvm-qemu

[AFS]

Si soporta Virtualizacion.

cat /proc/cpuinfo
processor: 0
vendor_id: AuthenticAMD
cpu family: 21
model: 2
model name: AMD FX(tm)-6300 Six-Core Processor
stepping: 0
microcode: 0x600081c
cpu MHz: 1793.726
cache size: 2048 KB
physical id: 0
siblings: 6
core id: 0
cpu cores: 3
apicid: 16
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid
aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes
xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr
tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat
npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists
pausefilter pfthreshold
bugs: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2
spec_store_bypass
bogomips: 7031.92
TLB size: 1536 4K pages
clflush size: 64
cache_alignment: 64
address sizes: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

Saludos

El 7 de agosto de 2018, 08:25, Eduardo Visbal
escribió:

> Buenos Dias Compañero
>
> Tu verificaste si tu hardware soporta vistualizacion?
>
> ejecuta este comando y plasma aqui el resultado:
>
> *egrep --color '(vmx|svm)' /proc/cpuinfo*
>
>
> *saludos*
>
>
>
> *Eduardo VisbalLinuxero #440451http://esdebianfritto.blogspot.com/
> *
>
>
> El mar., 7 ago. 2018 a las 9:22, AFS () escribió:
>
>> Buenos dias compañeros, tengo el problema que al abrir una nueva maquina
>> virtual el sistema se pone excesivamente lento, a la maquina virtual solo
>> le asigne 512 megas de RAM y aun asi el sistema se traba y tarda en
>> reaccionar, anteriormente tenia instalado el mismo paquete en la misma pc y
>> no presentaba ese problema.
>>
>> De los datos de mi equipo:
>>
>> uname -a
>> Linux fdez 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64
>> GNU/Linux
>>
>> qemu-kvm:
>>   Installed: 1:2.12+dfsg-3
>>
>> virt-manager:
>>   Installed: 1:1.5.1-1
>>
>> free -h
>>   totalusedfree  shared  buff/cache
>> available
>> Mem:  3.8Gi   1.5Gi   1.6Gi64Mi   721Mi
>> 2.1Gi
>> Swap: 7.4Gi  0B   7.4Gi
>>
>> df -h
>> FilesystemSize  Used Avail Use% Mounted on
>> udev  1.9G 0  1.9G   0% /dev
>> tmpfs 394M  6.7M  387M   2% /run
>> /dev/sda3  92G  4.3G   83G   5% /
>> tmpfs 2.0G   41M  1.9G   3% /dev/shm
>> tmpfs 5.0M 0  5.0M   0% /run/lock
>> tmpfs 2.0G 0  2.0G   0% /sys/fs/cgroup
>> /dev/sda1 735M   47M  635M   7% /boot
>> /dev/mapper/afs-home  1.9T  9.2G  1.8T   1% /home
>> /dev/mapper/afs-var   458G   41G  394G  10% /var
>> tmpfs 394M   16K  394M   1% /run/user/115
>> tmpfs 394M  3.5M  390M   1% /run/user/1000
>>
>> Gracias por su atención.
>>
>

Re: As seen above: use of su vs sudo

[The Wanderer]

On 2018-08-07 at 09:09, Nicolas George wrote:

> The Wanderer (2018-08-07):
> 
>> "su OPTIONAL_USERNAME -c 'YOUR_COMMAND'"
> 
> The superiority of sudu over su in this particular case is that it
> does not require an extra level of quoting.

I don't consider that a significant downside; in some contexts, it may
even be an advantage.

>> But it's more secure to require a second password to do elevated
>> things than to permit doing those things with the same password as
>> is used for ordinary activities.
> 
> That not necessarily true. A second password used for rare cases
> often means a password on a post-it under the keyboard.

An inclination in the direction of doing that would be a mark against
that user being considered sufficiently trustworthy to have the elevated
access to begin with.

>> Not usually; this is a desktop machine, not a server. Most logins
>> are done from a position of physical access.
>> 
>> Also, part of my entire point is that the "let users type their
>> password to confirm authorization to do elevated things" approach
>> means that anyone who learns the user's password can *both* log in
>> as the user *and* do those elevated things, which is clearly less
>> secure than if that just made it possible to log in as that user.
> 
> Anyone who learns the user's password can obtain the second password 
> pretty easily.

How so?

> Also, remember that what is really precious is access to user
> accounts. Root access is only a means to access any user's account.
> On a single-user machine, it is one and the same.

There's a point there, but I do consider the rest of the system (beyond
just the user's account) to be something worth securing, even on a
single-user system.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: As seen above: use of su vs sudo

[Dave Sherohman]

On Tue, Aug 07, 2018 at 12:22:53PM +0100, James Allsopp wrote:
> As far as I can see "su -" saves a lot of grief if you're the only admin on
> a system. Tried sudo ing to a protected directory? Doesn't work.

Works fine for me:

dave$ sudo bash
[sudo] password for dave:
root# cd /some/protected/dir
root# 

> Tired of entering your password every couple of minutes?

Even without using sudo to start a shell, it (by default) remembers that
you've already authenticated recently and you only have to re-enter your
password if you go more than 15 minutes without running a sudo command.

-- 
Dave Sherohman

Re: As seen above: use of su vs sudo

[Dave Sherohman]

On Tue, Aug 07, 2018 at 08:07:56AM -0400, The Wanderer wrote:
> On 2018-08-07 at 07:47, Martin wrote:
> > The point is not, that ONE person needs a root password. All people
> > intended to do privileged things will have to share this password.
> > This is a security nightmare!
> 
> If they're all trusted enough to be trusted with that password in the
> first place, this isn't a problem, any more than the one person having
> it is.
> 
> If they aren't trusted enough to have that password, why are we
> permitting them to do anything root-level in the first place?

It's not just a question of trust, but also one of maintenance.  What
happens when one of the people with root access gets a new job?

Using su and a shared root password:
- Disable the person's account.
- Change the root password.
- Find a secure way to distribute the new password to all the people
  it's shared by.

Using sudo:
- Disable the person's account.
- Remove the account from /etc/sudoers and/or the sudo group.

Everyone else with root access is completely unaffected by the
departure.

-- 
Dave Sherohman

Re: As seen above: use of su vs sudo

[The Wanderer]

On 2018-08-07 at 09:04, Martin wrote:

> Am 07.08.2018 um 14:50 schrieb The Wanderer:
> 
>> On 2018-08-07 at 08:27, Martin wrote:

>>> So, what is bad with 'sudo -u TARGETUSER YOUR_COMMEND'? How do
>>> you edit a file with su? Invoke a shell? Take a look at
>>> sudoedit!
>> 
>> "su OPTIONAL_USERNAME -c 'YOUR_COMMAND'", or similar, where 
>> 'YOUR_COMMAND' could be 'nano /path/to/file-to-be-edited' - or
>> could be 'sh', if it weren't possible to get a root shell by just
>> running straight 'su' instead.
> 
> Ouch!
> 
> Once you let a user run an editor with escalated privileges, you're
> fu**ed. In almost every editor, you can load a different file, save
> the buffer with a different file name.

Of course.

Again, that comes down to: do you trust this user with elevated access,
or not?

If you don't, you shouldn't be giving them elevated access of any kind.

If you do, then giving them this access doesn't hurt.

If you trust them with only limited elevated access, you should be
giving them access to a more limited role, not to root itself. It may be
reasonable to do that via sudoers (probably with targetpw, though I
haven't finished considering that subject), but it's also reasonable to
do it with separate users for each role.

(Combined with the fact that I didn't say I'd let most users do this; I
said this is what I do myself.)

> That is, why I pointed out the use of 'sudoedit'. You need to warp
> your mind around it, from a security standpoint, the use of 'su' is
> not a good idea in almost all cases.

I'm aware of this tool. It's not something I've ever needed, but it's
certainly valid for its purpose.

> And I still have no idea, what the single case would be, where sudo
> would not be able to do, what you may accomplish using su.

It's not that you can do something with su that you can't do with sudo.

It's that you can do things with sudo that you can't do with su.

Or, rather, that you can do elevated-access things with the same
credentials as are used to permit non-elevated access.

I consider that to be, by definition, a security hole.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Problema con kvm-qemu

[AFS]

Buenos dias compañeros, tengo el problema que al abrir una nueva maquina
virtual el sistema se pone excesivamente lento, a la maquina virtual solo
le asigne 512 megas de RAM y aun asi el sistema se traba y tarda en
reaccionar, anteriormente tenia instalado el mismo paquete en la misma pc y
no presentaba ese problema.

De los datos de mi equipo:

uname -a
Linux fdez 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64
GNU/Linux

qemu-kvm:
  Installed: 1:2.12+dfsg-3

virt-manager:
  Installed: 1:1.5.1-1

free -h
  totalusedfree  shared  buff/cache
available
Mem:  3.8Gi   1.5Gi   1.6Gi64Mi   721Mi
2.1Gi
Swap: 7.4Gi  0B   7.4Gi

df -h
FilesystemSize  Used Avail Use% Mounted on
udev  1.9G 0  1.9G   0% /dev
tmpfs 394M  6.7M  387M   2% /run
/dev/sda3  92G  4.3G   83G   5% /
tmpfs 2.0G   41M  1.9G   3% /dev/shm
tmpfs 5.0M 0  5.0M   0% /run/lock
tmpfs 2.0G 0  2.0G   0% /sys/fs/cgroup
/dev/sda1 735M   47M  635M   7% /boot
/dev/mapper/afs-home  1.9T  9.2G  1.8T   1% /home
/dev/mapper/afs-var   458G   41G  394G  10% /var
tmpfs 394M   16K  394M   1% /run/user/115
tmpfs 394M  3.5M  390M   1% /run/user/1000

Gracias por su atención.

Re: As seen above: use of su vs sudo

[Jonathan Dowland]

On Tue, Aug 07, 2018 at 11:46:55AM +, Curt wrote:

I've never used it myself. I'm all by my lonesome on this machine. I've
been using 'su' from the very beginning (but maybe I should start or
will start whenever the future and the new 'su' arrives using 'su -').


I've long forgotten why, but I committed "sudo su -" to muscle memory
sometime in the last two decades, and I'm mildly amused to see I'm
escaping the coming su-pocalypse unscathed.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Please help with error message

[Reco]

Hi.

On Tue, Aug 07, 2018 at 12:45:51PM +0200, Stephan Seitz wrote:
> On Di, Aug 07, 2018 at 01:18:59 +0300, Reco wrote:
> > > I never had your mentioned problems.
> > Either you have /sbin in your user's path, or you haven't run a single
> > apt-get all these years. There are other possibilities, of course,
> > though less flattering.
> 
> Bullshit again. You didn’t read the thread, did you?

Tsk-tsk. Personal attacks on debian-user, and it's not even a Friday.

> This is new behaviour in testing because Debian switched the source for the
> su binary.
> 
> Debian 9:
> stse@fsing:~$ echo $PATH
> /home/stse/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> stse@fsing:~$ su
> Passwort:
> root@fsing /home/stse # echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> 
> Testing:
> [stse@osgiliath]: echo $PATH
> /home/stse/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/stse/wego/bin
> [stse@osgiliath]: su
> Passwort:
> osgiliath:/home/stse# echo $PATH
> /home/stse/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/stse/wego/bin
> 
> Testing with „ALWAYS_SET_PATH yes” in login.defs:
> [stse@osgiliath]: echo $PATH
> /home/stse/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/stse/wego/bin
> [stse@osgiliath]: su
> Passwort:
> osgiliath:/home/stse# echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> 
> I hope you see the difference.

So once again Debian aligned its behaviour with RHEL. Not the first
time, not the last. A interesting change, but a minor one.
All of us using 'su -' all these years are not affected.
Users of ordinary 'su' may suffer though.


> 
> > > „su” doesn’t change the working directory. So if you compile
> > > software as a user you can then type „make install” after su.
> > True. But this tidbit does not relate to this particular problem at all.
> 
> It does. Depending on your needs you could use „su” or „su -”.

And you're telling me to read the thread. How exactly apt-get's
behaviour depends on cwd?


> > > If you need to run an X11 program as root su preserved the DISPLAY
> > > variable.
> > And it also preserves $HOME. So any changed configuration file will be
> > owned by root. Not a big deal if you never try to run the program in
> 
> Only if the file never existed.

Or program's developer is trying being smart and writes changed
configuration in a different file followed by rename(2).

> 
> > > Luckily you can switch back to the old behaviour, but this should be
> > > the default.
> > Care to provide a Debian bug number that you filled on this particular
> > issue? Because rants on debian-user do not transform to patches by
> > themselves.
> 
> Which patches?

You're expressing a strong dislike of a certain change, but you're doing
so in a wrong place. An appropriate place for such dislikes is called
bugs.debian.org, and all the changes of behaviour are accepted in the
form of patches to source packages theres.


> > > As Linus would say: „Don’t break user behaviour! Give them an
> > > option to switch to a new one.”.
> > A recent kernel update (linux-4.9.110-3+deb9u1) begs to differ.
> > Two notable behaviour changes without any way to disable them.
> 
> Are these security changes? Then Linus permits it if there is no other way.
> By the way, what are these changes that are breaking user space?

Too lazy to read the changelog, eh?
Fix for CVE-2018-13405 breaks directory permissions.
Fix for CVE-2018-5390 changes TCP stack.

Reco

Re: As seen above: use of su vs sudo

[Michael Stone]

On Tue, Aug 07, 2018 at 02:27:48PM +0200, Martin wrote:

Am 07.08.2018 um 14:07 schrieb The Wanderer:

On 2018-08-07 at 07:47, Martin wrote:

As a system operator, you need some elevated privileges on a daily
basis. How do you do that without sudo?


No, I don't. I only need them when I'm doing elevated things, such as
installs or upgrades. (In practice on some machines, I do those on
around a weekly basis or slightly more frequently, but it can be argued
that that's overkill.) The overwhelming majority of what I do does not
require elevated privileges, and the few things which do are not needed
anywhere near daily.


Starting and stopping services (e.g. running systemctl), changing 
configurations, all things you, where individual decisions have to be made, 
reuire elevated privileges. root in many cases.


It's ironic that while forcefully telling people they're doing it wrong, 
you're managing a bunch of machines with no configuration management, 
manually editing files directly on systems. You have your preferred way 
of doing things, other people do things other ways. I don't think there 
are any new points here, so please stop repeating that yours is the only 
correct way to operate so the thread can die a natural death.


Mike Stone

Re: comment récupérer altgr au clavier

[Bernard Schoenacker]

- Mail original -
> De: "Alexandre Hoïde" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mardi 7 Août 2018 12:54:54
> Objet: Re: comment récupérer altgr au clavier
> 
> On Tue, Aug 07, 2018 at 12:43:10PM +0200, Bernard Schoenacker wrote:
> > ce qui est gonflant c'est de mettre un clavier usb qui fonctionne
> > bien
> > et sans soucis ...
> > 
> > c'est de toute façon pour un asus eee pc seashell
> 
>   Oui, c'est certainement gonflant ! Mais commence par voir si '$
>   xev'
> détecte le AltGr du clavier intégré. Faut aller du plus simple au
> plus
> compliqué. T'auras tout le temps pour gonfler après. ^^
> 
>   Complément d'info pour la console, les outils seraient loadkeys,
> dumpkeys et keymaps.
> 
> PS Merci d'envoyer les réponses uniquement à la liste.

bonjour,
j'ai essayé xev et je n'ai aucun signal sur altgr ...

j'ai l'impression que le clavier est hs

merci
slt
bernard

Re: As seen above: use of su vs sudo

[Nicolas George]

The Wanderer (2018-08-07):
> "su OPTIONAL_USERNAME -c 'YOUR_COMMAND'"

The superiority of sudu over su in this particular case is that it does
not require an extra level of quoting.

> But it's more secure to require a second password to do elevated things
> than to permit doing those things with the same password as is used for
> ordinary activities.

That not necessarily true. A second password used for rare cases often
means a password on a post-it under the keyboard.

> Not usually; this is a desktop machine, not a server. Most logins are
> done from a position of physical access.
> 
> Also, part of my entire point is that the "let users type their password
> to confirm authorization to do elevated things" approach means that
> anyone who learns the user's password can *both* log in as the user
> *and* do those elevated things, which is clearly less secure than if
> that just made it possible to log in as that user.

Anyone who learns the user's password can obtain the second password
pretty easily.

Also, remember that what is really precious is access to user accounts.
Root access is only a means to access any user's account. On a
single-user machine, it is one and the same.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: question about sound

[mick crane]

On 2018-08-07 07:30, deloptes wrote:

mick crane wrote:


I'm not very good at sound.
Sometimes if I watch an mp4 film the volume in parts is low but then
there will become some sound event that is very loud.
It is true that my hearing is not as it was but I don't think that is
it.
I'm not exactly sure what controls "volume" but is there software that
will cut off the noisier bits at a level without affecting the rest.


I think the whole problem comes from the surround channels - why not 
check

the options around mixing multiple channels into L/R


that makes sense for an explanation

mick


--
Key ID4BFEBB31

Re: As seen above: use of su vs sudo

[Martin]

Am 07.08.2018 um 14:50 schrieb The Wanderer:
> On 2018-08-07 at 08:27, Martin wrote:
> 
>> Am 07.08.2018 um 14:07 schrieb The Wanderer:
>>
>>> On 2018-08-07 at 07:47, Martin wrote:
> 
 As a system operator, you need some elevated privileges on a
 daily basis. How do you do that without sudo?
>>>
>>> No, I don't. I only need them when I'm doing elevated things, such
>>> as installs or upgrades. (In practice on some machines, I do those
>>> on around a weekly basis or slightly more frequently, but it can
>>> be argued that that's overkill.) The overwhelming majority of what
>>> I do does not require elevated privileges, and the few things
>>> which do are not needed anywhere near daily.
>>
>> Starting and stopping services (e.g. running systemctl), changing
>> configurations, all things you, where individual decisions have to
>> be made, reuire elevated privileges. root in many cases.
> 
> And none of those are things I need to do as frequently as on a daily
> basis.
>>> How I do them is by running either "su -c 'command name'", or
>>> simply running 'su' and then running the desired command(s) and
>>> then exiting the root shell.
>>
>> So, what is bad with 'sudo -u TARGETUSER YOUR_COMMEND'? How do you
>> edit a file with su? Invoke a shell? Take a look at sudoedit!
> 
> "su OPTIONAL_USERNAME -c 'YOUR_COMMAND'", or similar, where
> 'YOUR_COMMAND' could be 'nano /path/to/file-to-be-edited' - or could be
> 'sh', if it weren't possible to get a root shell by just running
> straight 'su' instead.

Ouch!
Once you let a user run an editor with escalated privileges, you're fu**ed. In 
almost every editor, you can load a different file, save the buffer with a 
different file name. 
That is, why I pointed out the use of 'sudoedit'. You need to warp your mind 
around it, from a security standpoint, the use of 'su' is not a good idea in 
almost all cases.
And I still have no idea, what the single case would be, where sudo would not 
be able to do, what you may accomplish using su.

[...]

Re: Kernel 4.9.0-7-686 Installed RAM vs. uabale RAM

[Michael Stone]

On Tue, Aug 07, 2018 at 02:53:18PM +0200, basti wrote:

Hello, I have a system with Kernel 4.9.0-7-686, installed RAM are 3x 1GB
but free -m only show 2GB.

Whats wrong here?


Install a -pae kernel.

Mike Stone

Kernel 4.9.0-7-686 Installed RAM vs. uabale RAM

[basti]

Hello, I have a system with Kernel 4.9.0-7-686, installed RAM are 3x 1GB
but free -m only show 2GB.

Whats wrong here?

# free -m
  total    used    free  shared  buff/cache  
available
Mem:   2018 203    1204  25
610    1569
Swap:  8191   0    8191


# dmidecode -t 17
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.4 present.

Handle 0x0029, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x0028
    Error Information Handle: No Error
    Total Width: 72 bits
    Data Width: 64 bits
    Size: 1024 MB
    Form Factor: DIMM
    Set: None
    Locator: DIMM-1A
    Bank Locator: Not Specified
    Type: DDR2
    Type Detail: Synchronous
    Speed: 800 MHz
    Manufacturer: Not Specified
    Serial Number: Not Specified
    Asset Tag: Not Specified
    Part Number: Not Specified

Handle 0x002A, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x0028
    Error Information Handle: No Error
    Total Width: 72 bits
    Data Width: 64 bits
    Size: 1024 MB
    Form Factor: DIMM
    Set: None
    Locator: DIMM-2A
    Bank Locator: Not Specified
    Type: DDR2
    Type Detail: Synchronous
    Speed: 800 MHz
    Manufacturer: Not Specified
    Serial Number: Not Specified
    Asset Tag: Not Specified
    Part Number: Not Specified

Handle 0x002B, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x0028
    Error Information Handle: No Error
    Total Width: 72 bits
    Data Width: 64 bits
    Size: 1024 MB
    Form Factor: DIMM
    Set: None
    Locator: DIMM-1B
    Bank Locator: Not Specified
    Type: DDR2
    Type Detail: Synchronous
    Speed: 800 MHz
    Manufacturer: Not Specified
    Serial Number: Not Specified
    Asset Tag: Not Specified
    Part Number: Not Specified

Handle 0x002C, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x0028
    Error Information Handle: No Error
    Total Width: Unknown
    Data Width: Unknown
    Size: No Module Installed
    Form Factor: DIMM
    Set: None
    Locator: DIMM-2B
    Bank Locator: Not Specified
    Type: DDR2
    Type Detail: Synchronous
    Speed: 800 MHz
    Manufacturer: Not Specified
    Serial Number: Not Specified
    Asset Tag: Not Specified
    Part Number: Not Specified


As I know 6868 can address 4GB RAM

Best Regards,

Re: As seen above: use of su vs sudo

[The Wanderer]

On 2018-08-07 at 08:27, Martin wrote:

> Am 07.08.2018 um 14:07 schrieb The Wanderer:
> 
>> On 2018-08-07 at 07:47, Martin wrote:

>>> As a system operator, you need some elevated privileges on a
>>> daily basis. How do you do that without sudo?
>> 
>> No, I don't. I only need them when I'm doing elevated things, such
>> as installs or upgrades. (In practice on some machines, I do those
>> on around a weekly basis or slightly more frequently, but it can
>> be argued that that's overkill.) The overwhelming majority of what
>> I do does not require elevated privileges, and the few things
>> which do are not needed anywhere near daily.
> 
> Starting and stopping services (e.g. running systemctl), changing
> configurations, all things you, where individual decisions have to
> be made, reuire elevated privileges. root in many cases.

And none of those are things I need to do as frequently as on a daily
basis.

>> How I do them is by running either "su -c 'command name'", or
>> simply running 'su' and then running the desired command(s) and
>> then exiting the root shell.
> 
> So, what is bad with 'sudo -u TARGETUSER YOUR_COMMEND'? How do you
> edit a file with su? Invoke a shell? Take a look at sudoedit!

"su OPTIONAL_USERNAME -c 'YOUR_COMMAND'", or similar, where
'YOUR_COMMAND' could be 'nano /path/to/file-to-be-edited' - or could be
'sh', if it weren't possible to get a root shell by just running
straight 'su' instead.

>>> The point is not, that ONE person needs a root password. All 
>>> people intended to do privileged things will have to share this 
>>> password. This is a security nightmare!
>> 
>> If they're all trusted enough to be trusted with that password in 
>> the first place, this isn't a problem, any more than the one
>> person having it is.
> 
> Come on. You are telling me, it is more secure to share one secret 
> among multiple people against every person having it own?

Of course not.

But it's more secure to require a second password to do elevated things
than to permit doing those things with the same password as is used for
ordinary activities.

>>> So you are spreading even more passwords around the world... No.
>> 
>> How is this less secure than permitting "anyone who happens to 
>> discover the password of $random_user" to do (some) root-level 
>> things?
> 
> First you have to log in to a user's account. And I'm quite sure,
> you will use ssh with keys that, right?

Not usually; this is a desktop machine, not a server. Most logins are
done from a position of physical access.

Also, part of my entire point is that the "let users type their password
to confirm authorization to do elevated things" approach means that
anyone who learns the user's password can *both* log in as the user
*and* do those elevated things, which is clearly less secure than if
that just made it possible to log in as that user.

>> At the very worst, it means that if the 
>> limited-access-for-this-role password leaks, you A: just have to 
>> change that one password and B: haven't had the entire system 
>> compromised.
> 
> What?

I'm not sure what you're asking.

>>> Ok, you have not read the sudo man page, neither understood the 
>>> concept. And why you do _not_ want to use 'targetpw'. No
>>> offence, but you really need to thin about your thesis on
>>> privilege management.
>> 
>> The relevant man page is actually sudoers, and you're right; I did
>> search it for 'user' and "password" in the hopes of finding a way 
>> to do this, but apparently managed not to find this term, even 
>> though it's there. That does open up some interesting 
>> possibilities.
> 
> Please, don't use 'targewtpw'. It is evil. Thin about that: Every 
> individual has to log in on a shell. SSH keys are used for that.

I think this may be our first point of disconnect. I'm not expecting
most, or even a significant fraction of, logins to be done remotely.

I originally approached this from the model of a shared physical
computer (and monitor, and keyboard, and so forth), which has different
people sitting down in front of it - logged in with their own accounts,
either local or network-authenticated - at different times of day.

Most users might not even be authorized for SSH login in the first
place.

(I'm not sure I fully understand SSH key-based login, but I'm also not
entirely comfortable with what I think it would require in order for
someone to be able to log in from whatever random computer they happen
to be at; I would expect that to result in too much risk of the keys
being exposed.)

> Than every individual has to set a password. May be even in some
> directory or so.

I'm not quite sure what you're talking about here. The user's password
must already exist in order for the user to log in, because the password
gets set when the user's account gets created. Are you talking about
some additional password, attached to the same user account? And what
directory are you talking about? (Is this a reference to LDAP, rather
than to 

Re: As seen above: use of su vs sudo

[likcoras]

On 08/07/2018 09:06 PM, Joe wrote:
> On Tue, 7 Aug 2018 12:11:50 +0100
> Jonathan Dowland  wrote:
>> If you set a root password in d-i (as it asks you to), it doesn't
>> install sudo. If you try to set a blank root password, it locks the
>> root account, installs sudo and sets up the user you created with sudo
>> access.
>>
> 
> OK, I've never tried that. I always want the option of connecting a
> monitor and actually logging in as root, just in case of
> difficulties. I believe that some boot problems are not solveable
> without being able to provide a root password, long before the
> operating system can provide su or sudo.

In those truly catastrophic cases, you can set init=/bin/sh in the
bootloader kernel line, which will boot you into a root shell.

Re: As seen above: use of su vs sudo

[Martin]

Am 07.08.2018 um 14:19 schrieb Stephan Seitz:
> On Di, Aug 07, 2018 at 11:46:55 +, Curt wrote:
>> But it seems the whole point of the thing in a multi-user environment is
>> that you can use a granular approach to permissions, so I suppose if you
>> didn't desire a particular user modifying the logs, while granting her
>> other administrative privileges, that would fall completely within the
>> purview of the philosophy and implementation of the soft that is 'sudo'.
> 
> Exactly. At home I’m the only person using my computer, so I don’t need the 
> sudo philosophy.
> 
> At work we’re using sudo (interestingly without asked password, so if you 
> could login, you can do „sudo -i”), but there is no administrator difference. 
> Everyone in our small group has always full administrator access.

It's the NOPASSWD directive in sudoers.

> 
> Shade and sweet water!
> 
> Stephan
> 

Re: As seen above: use of su vs sudo

[Martin]

Am 07.08.2018 um 14:07 schrieb The Wanderer:
> On 2018-08-07 at 07:47, Martin wrote:
> 
>> Am 07.08.2018 um 13:20 schrieb The Wanderer:
>>
>>> On 2018-08-07 at 05:58, Martin Drescher wrote:
>>>
 Hi members,

 I'm a little... lets say thoughtful, about the use of 'su'
 discussed at some points in this list. I have a strong opinion
 about su, which is, avoid it whenever it is possible and use
 'sudo' instead. This is the case in close to a 100% in all cases
 I can think of. This opinion is based on how both programs work
 and deal with pam and environmental variables. Not to forget: You
 will not need to share (or in my case, not even set, but lock
 that account) a root password.

 And I'm curious why Debian still prefers the use of su over
 sudo?
>>>
>>> I'm not sure where you get the idea that Debian does prefer that.
>>
>> It is not part of the base install. Besides the statement from
>> Jonathan Dowland earlier.
> 
> I'm fairly sure that when I did (some of) my existing installs - which,
> to be fair, was years and years ago - sudo came with the system, even
> though I didn't even consider the concept of setting the machine up with
> no root password. Maybe this has changed at some point.

See Jonathan Dowland at 11:11 UTC.
 
>>> For my own machines to date (on most if not all of which I'm the
>>> primary if not sole user, or at least non-remote user), I don't
>>> even permit sudo to be installed. (Or at least I didn't, until I
>>> decided I wanted ubuntu-dev-tools - which depends on it - on one
>>> such machine. I may even revert that decision on further
>>> consideration.)
>>
>> As a system operator, you need some elevated privileges on a daily
>> basis. How do you do that without sudo?
> 
> No, I don't. I only need them when I'm doing elevated things, such as
> installs or upgrades. (In practice on some machines, I do those on
> around a weekly basis or slightly more frequently, but it can be argued
> that that's overkill.) The overwhelming majority of what I do does not
> require elevated privileges, and the few things which do are not needed
> anywhere near daily.

Starting and stopping services (e.g. running systemctl), changing 
configurations, all things you, where individual decisions have to be made, 
reuire elevated privileges. root in many cases.
 
> How I do them is by running either "su -c 'command name'", or simply
> running 'su' and then running the desired command(s) and then exiting
> the root shell.

So, what is bad with 'sudo -u TARGETUSER YOUR_COMMEND'?
How do you edit a file with su? Invoke a shell? Take a look at sudoedit!

>>> My rationale for doing that is (in crude form) that to permit any 
>>> root-level things to be done with an ordinary user's password -
>>> even mediated by a task-limiting mechanism such as I understand
>>> /etc/sudoers to be - is a security hole; not only is an ordinary
>>> user's password more likely to leak (whether by social engineering
>>> or by malicious code running as the user or by anything in
>>> between), if you're not trusted to have the root password in
>>> addition to your own, you shouldn't be doing any root-needing
>>> things in the first place.
>>
>> The point is not, that ONE person needs a root password. All people
>> intended to do privileged things will have to share this password.
>> This is a security nightmare!
> 
> If they're all trusted enough to be trusted with that password in the
> first place, this isn't a problem, any more than the one person having
> it is.

Come on. You are telling me, it is more secure to share one secret among 
multiple people against every person having it own?

> If they aren't trusted enough to have that password, why are we
> permitting them to do anything root-level in the first place?
> 
> That said, I recognize this concern, and it's a large part of why I
> moderated my position somewhat over the years.
> 
>>> Over the years, I've moderated that position somewhat, enough to
>>> concede that there may be value in being able to hand out the
>>> ability to do some elevated-access things without handing out the
>>> ability to do all of them. That would just mean I'd want to set up
>>> various other (non-root, non-ordinary) users, with their own
>>> passwords and the necessary access to do those specific things, and
>>> hand out those passwords instead. (And
>>
>> So you are spreading even more passwords around the world... No.
> 
> How is this less secure than permitting "anyone who happens to discover
> the password of $random_user" to do (some) root-level things?

First you have to log in to a user's account. And I'm quite sure, you will use 
ssh with keys that, right?

> At the very worst, it means that if the limited-access-for-this-role
> password leaks, you A: just have to change that one password and B:
> haven't had the entire system compromised.

What?

> (An alternative approach would be one "elevated" account per user, used
> only for 

Re: As seen above: use of su vs sudo

[Stephan Seitz]

On Di, Aug 07, 2018 at 01:33:20 +0200, Martin wrote:
I don’t know if Debian does, but the difference between su and sudo 
seems quite like to the difference between ssh logins with password 
and with keys. Both have advantages and disadvantages.

By far: No.
su only invokes or acts like login, pam included. sudo may represent a complex 
role management.


Yes, I know. Maybe I wasn’t clear enough. Both tools provide a solution, 
and it is your philosphy/rule set that will decide if solution A is 
better for your work or solution B.


Shade and sweet water!

Stephan

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


smime.p7s
Description: S/MIME cryptographic signature

Re: As seen above: use of su vs sudo

[Stephan Seitz]

On Di, Aug 07, 2018 at 11:46:55 +, Curt wrote:

But it seems the whole point of the thing in a multi-user environment is
that you can use a granular approach to permissions, so I suppose if you
didn't desire a particular user modifying the logs, while granting her
other administrative privileges, that would fall completely within the
purview of the philosophy and implementation of the soft that is 'sudo'.


Exactly. At home I’m the only person using my computer, so I don’t need 
the sudo philosophy.


At work we’re using sudo (interestingly without asked password, so if you 
could login, you can do „sudo -i”), but there is no administrator 
difference. Everyone in our small group has always full administrator 
access.


Shade and sweet water!

Stephan

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


smime.p7s
Description: S/MIME cryptographic signature

Re: As seen above: use of su vs sudo

[Eike Lantzsch]

On Tuesday, August 7, 2018 11:58:48 AM -04 Martin Drescher wrote:
> Hi members,
> 
> I'm a little... lets say thoughtful, about the use of 'su' discussed at some
> points in this list. I have a strong opinion about su, which is, avoid it
> whenever it is possible and use 'sudo' instead. This is the case in close
> to a 100% in all cases I can think of. This opinion is based on how both
> programs work and deal with pam and environmental variables. Not to forget:
> You will not need to share (or in my case, not even set, but lock that
> account) a root password.
> 
> And I'm curious why Debian still prefers the use of su over sudo?
> 
> 
> Martin.

What ever one prefers, I recommend the following discussion:
https://www.youtube.com/watch?v=o0purspHg-o

and this book:
https://www.michaelwlucas.com/tools/sudo

Cheers
Eike

Re: New `no sound' problems

[Curt]

On 2018-08-07, Rodolfo Medina  wrote:
> deloptes  writes:
>
>> Rodolfo Medina wrote:
>>
>>> After yesterday's full-upgrade
>>> in Sid
>>
>> well this is self explaining -> Sid

He means it's self-explanatory given you're using testing and when using 
testing shit
happens (things break). It goes with the territory and is in the nature
of the beast you've chosen to tame (or wrangle with).

That's my interpretation anyway.

>
> What please do you mean...?
>
> Rodolfo
>
>


-- 
Some years ago, when the images which this world affords first opened upon me,
when I felt the cheering warmth of summer and heard the rustling of the leaves
and the warbling of the birds, and these were all to me, I should have wept to
die; now it is my only consolation. --Mary Shelley, Frankenstein; or, The 
Modern Prometheus

Re: Please help with error message

[Greg Wooledge]

On Tue, Aug 07, 2018 at 01:18:59PM +0300, Reco wrote:
> On Tue, Aug 07, 2018 at 12:01:02PM +0200, Stephan Seitz wrote:
> > On Di, Aug 07, 2018 at 12:35:32 +0300, Reco wrote:
> > > > rodolfo@sda6-acer:~$ su
> > > Don't. Do. That. Ever.
> > 
> > That’s bullshit. I did it all the time until Debian decided to break things.

> Either you have /sbin in your user's path, or you haven't run a single
> apt-get all these years. There are other possibilities, of course,
> though less flattering.

No, Stephan is correct.  In Debian stable, "su" with no arguments
changes PATH.  It has done so for years.  Decades, if I'm not mistaken.

Here, watch:

wooledg:~$ echo "$PATH"
/home/wooledg/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
wooledg:~$ su
Password: 
root@wooledg:/home/wooledg# echo "$PATH"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

If testing/unstable has changed this behavior, then that's going to be
a HUGE thing to adjust to.  Has a bug been filed for it yet?

Re: Asck some information for start to help Debian

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 07, 2018 at 01:26:35PM +0200, Ehsan Esteki wrote:
> I never riceve the answer from my email.
> Can you give me please the feedabck.

Hi, Ehsan,

(CC'ing Ehsan, just in case)

There were several answers. Perhaps you are not subscribed to the
list? Or something else is not working.

Just in case, you can read your mail and all the answers in
the mail list archive:

  https://lists.debian.org/debian-user/2018/08/msg00193.html

I hope you receive this mail.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAltpjT0ACgkQBcgs9XrR2kZDTgCffA753gn8Re2CMJhitKErp8DB
IC8AnAu1k53k3iz4COF0Bm9U5BMTna4j
=X/FA
-END PGP SIGNATURE-

Re: As seen above: use of su vs sudo

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 07, 2018 at 12:22:53PM +0100, James Allsopp wrote:
> As far as I can see "su -" saves a lot of grief if you're the only admin on
> a system. Tried sudo ing to a protected directory? Doesn't work. Tired of
> entering your password every couple of minutes?

There's "sudo -s" for that, as in "gimme a root shell".

> sudo does mean that the admin actions of a particular user are logged, but
> unless you lock down what they can do, they can change/delete the logs
> easily enough.

That's not the main point of sudo. Yes, you can control it in many
fine-grained ways, which is a boon if you want to give (somewhat
restricted) powers to e.g. a backup script.

> I think this just degenerates into a religious war [...]

This makes as much sense as having a religious war in the workshop
on whether a Phillips screwdriver is "better" than a circular saw.

Ever tried to tighten a Phillips screw with a circular saw?

Enjoy your tools. Get to know them, and pick. Me, I've never needed
su since I got the hang of sudo, but why would I want to force anyone
to do the same?

OTOH, I don't like the idea of a passwordless root (my dislike comes
from the first time I went with that and stood in front of a machine
with a broken root file system telling me to enter the root password
to fix things :-)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAltpjB4ACgkQBcgs9XrR2kZv/gCggF3+9FcemzsJ0ISMrhFtf8eM
AzUAn0OPybYmMuq+Nd6z4LroDa04R0U+
=3TtR
-END PGP SIGNATURE-

Re: New `no sound' problems

[Rodolfo Medina]

Jude DaShiell  writes:

> On Tue, 7 Aug 2018, Rodolfo Medina wrote:
>
>> Date: Tue, 7 Aug 2018 06:40:49
>> From: Rodolfo Medina 
>> To: debian-user@lists.debian.org
>> Subject: Re: New `no sound' problems
>> Resent-Date: Tue,  7 Aug 2018 10:41:15 + (UTC)
>> Resent-From: debian-user@lists.debian.org
>>
>> Rodolfo Medina  writes:
>>
>> > It seems to be damned recursive, the problem...  After yesterday's
>> > full-upgrade in Sid, my old Acer One without sound once again...
>> > Everything seems all right: alsamixer, aumix, pulseaudio installed...
>> > Last time this happened, it was solved installing pulseaudio and
>> > alsaplayer-alsa...  Now it won't...  Please help.
>>
>>
>> Also mplayer's output seems all right:
>>
>> $ playfile timmy_thomas08-opportunity.wav
>> MPlayer 1.3.0 (Debian), built with gcc-7 (C) 2000-2016 MPlayer Team
>> do_connect: could not connect to socket
>> connect: No such file or directory
>> Failed to open LIRC support. You will not be able to use your remote control.
>>
>> Playing timmy_thomas08-opportunity.wav.
>> libavformat version 58.12.100 (external)
>> libavformat file format detected.
>> [lavf] stream 0: audio (pcm_s16le), -aid 0
>> Clip info:
>>  artist: Timmy Thomas
>>  comment: source: spotify
>>  genre: blues
>>  title: timmy_thomas08-opportunity
>>  album: Why can't we live together
>>  encoder: Lavf57.71.100
>> Load subtitles in ./
>> ==
>> Opening audio decoder: [pcm] Uncompressed PCM audio decoder
>> AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
>> Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
>> ==
>> AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
>> Video: no video
>> Starting playback...
>> A:   0.0 (00.0) of 189.0 (03:09.0) ??,?%
>>
>>
>> but no sound at all.
>>
>> Rodolfo
>>
> Does speakertest produce any static?  I'm thinking speakertest could do
> with an enhancement which would help anyone without sound tremendously.
> Specifically, don't ask for sound card and device on command line at all
> and cycle through everything it can find using aplay -l output.  Have
> speakertest play something other than static and put a question up on the
> screen after each device is tried asking the user if they can hear the
> sample sound.  Once a positive response is gotten, print out on the
> screen the card and device and ask the user if they'd like those stored
> and a positive response would then run alsactl store.   Pulseaudio is
> another problem level and has worked so poorly in the past at times here
> I'm not really sure how to improve that.


This is speaker-test output:

$ speaker-test

speaker-test 1.1.6

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 192 to 2097152
Period size range from 64 to 699051
Using max buffer size 2097152
Periods = 4
was set period_size = 524288
was set buffer_size = 2097152
 0 - Front Left
Time per period = 12.491143
 0 - Front Left
Time per period = 12.489111
 0 - Front Left
Time per period = 12.490776
 0 - Front Left
Time per period = 12.490342
 0 - Front Left
Time per period = 12.488501
 0 - Front Left

What then...?

Thanks,

Rodolfo

Re: As seen above: use of su vs sudo

[The Wanderer]

On 2018-08-07 at 07:47, Martin wrote:

> Am 07.08.2018 um 13:20 schrieb The Wanderer:
> 
>> On 2018-08-07 at 05:58, Martin Drescher wrote:
>> 
>>> Hi members,
>>> 
>>> I'm a little... lets say thoughtful, about the use of 'su'
>>> discussed at some points in this list. I have a strong opinion
>>> about su, which is, avoid it whenever it is possible and use
>>> 'sudo' instead. This is the case in close to a 100% in all cases
>>> I can think of. This opinion is based on how both programs work
>>> and deal with pam and environmental variables. Not to forget: You
>>> will not need to share (or in my case, not even set, but lock
>>> that account) a root password.
>>> 
>>> And I'm curious why Debian still prefers the use of su over
>>> sudo?
>> 
>> I'm not sure where you get the idea that Debian does prefer that.
> 
> It is not part of the base install. Besides the statement from
> Jonathan Dowland earlier.

I'm fairly sure that when I did (some of) my existing installs - which,
to be fair, was years and years ago - sudo came with the system, even
though I didn't even consider the concept of setting the machine up with
no root password. Maybe this has changed at some point.

>> For my own machines to date (on most if not all of which I'm the
>> primary if not sole user, or at least non-remote user), I don't
>> even permit sudo to be installed. (Or at least I didn't, until I
>> decided I wanted ubuntu-dev-tools - which depends on it - on one
>> such machine. I may even revert that decision on further
>> consideration.)
> 
> As a system operator, you need some elevated privileges on a daily
> basis. How do you do that without sudo?

No, I don't. I only need them when I'm doing elevated things, such as
installs or upgrades. (In practice on some machines, I do those on
around a weekly basis or slightly more frequently, but it can be argued
that that's overkill.) The overwhelming majority of what I do does not
require elevated privileges, and the few things which do are not needed
anywhere near daily.

How I do them is by running either "su -c 'command name'", or simply
running 'su' and then running the desired command(s) and then exiting
the root shell.

>> My rationale for doing that is (in crude form) that to permit any 
>> root-level things to be done with an ordinary user's password -
>> even mediated by a task-limiting mechanism such as I understand
>> /etc/sudoers to be - is a security hole; not only is an ordinary
>> user's password more likely to leak (whether by social engineering
>> or by malicious code running as the user or by anything in
>> between), if you're not trusted to have the root password in
>> addition to your own, you shouldn't be doing any root-needing
>> things in the first place.
> 
> The point is not, that ONE person needs a root password. All people
> intended to do privileged things will have to share this password.
> This is a security nightmare!

If they're all trusted enough to be trusted with that password in the
first place, this isn't a problem, any more than the one person having
it is.

If they aren't trusted enough to have that password, why are we
permitting them to do anything root-level in the first place?

That said, I recognize this concern, and it's a large part of why I
moderated my position somewhat over the years.

>> Over the years, I've moderated that position somewhat, enough to
>> concede that there may be value in being able to hand out the
>> ability to do some elevated-access things without handing out the
>> ability to do all of them. That would just mean I'd want to set up
>> various other (non-root, non-ordinary) users, with their own
>> passwords and the necessary access to do those specific things, and
>> hand out those passwords instead. (And
> 
> So you are spreading even more passwords around the world... No.

How is this less secure than permitting "anyone who happens to discover
the password of $random_user" to do (some) root-level things?

At the very worst, it means that if the limited-access-for-this-role
password leaks, you A: just have to change that one password and B:
haven't had the entire system compromised.

(An alternative approach would be one "elevated" account per user, used
only for elevated tasks and possibly even prohibited from logging in, so
that if the user's normal password leaks that doesn't compromise
elevated access. I think that would have too many downsides, however.)

>> still probably have people use something like 'su -c' instead of
>> sudo, unless sudo permits requiring the password of a user other
>> than the one invoking the command.)
> 
> Ok, you have not read the sudo man page, neither understood the
> concept. And why you do _not_ want to use 'targetpw'. No offence, but
> you really need to thin about your thesis on privilege management.

The relevant man page is actually sudoers, and you're right; I did
search it for 'user' and "password" in the hopes of finding a way to do
this, but apparently managed not to find 

Re: Please help with error message

[mick crane]

On 2018-08-07 12:47, mick crane wrote:

On 2018-08-07 09:18, Stephan Seitz wrote:

On Di, Aug 07, 2018 at 10:08:06 +0200, Rodolfo Medina wrote:

$ echo $PATH
/home/rodolfo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
rodolfo@sda6-acer:~$ su
Password:


You are using testing/unstable, aren’t you?




so where is user's path kept these days as it seems I might have set
user PATH to root PATH ?
and I should probably put it back as it was.
mick


OK seems set $PATH after su does change root PATH so things are as they 
were


--
Key ID4BFEBB31

Re: As seen above: use of su vs sudo

[Joe]

On Tue, 7 Aug 2018 12:11:50 +0100
Jonathan Dowland  wrote:

> On Tue, Aug 07, 2018 at 11:40:29AM +0100, Joe wrote:
> >Why, I don't know, but the last time I installed stable, sudo was not
> >installed by default, and never has been in my experience. I always
> >add sudo and mc immediately after an installation.  
> 
> If you set a root password in d-i (as it asks you to), it doesn't
> install sudo. If you try to set a blank root password, it locks the
> root account, installs sudo and sets up the user you created with sudo
> access.
> 

OK, I've never tried that. I always want the option of connecting a
monitor and actually logging in as root, just in case of
difficulties. I believe that some boot problems are not solveable
without being able to provide a root password, long before the
operating system can provide su or sudo.

-- 
Joe

Re: New `no sound' problems

[Rodolfo Medina]

deloptes  writes:

> Rodolfo Medina wrote:
>
>> After yesterday's full-upgrade
>> in Sid
>
> well this is self explaining -> Sid


What please do you mean...?

Rodolfo

Re: As seen above: use of su vs sudo

[likcoras]

On 08/07/2018 07:40 PM, Joe wrote:
> On Tue, 7 Aug 2018 11:58:48 +0200
> Why, I don't know, but the last time I installed stable, sudo was not
> installed by default, and never has been in my experience. I always add
> sudo and mc immediately after an installation.

It's installed if you choose to 'disallow login as root' during
installation, which then would prompt you to create a user that will
automatically be given sudo access (by being in the sudo group).

Re: As seen above: use of su vs sudo

[Curt]

On 2018-08-07, James Allsopp  wrote:
>
> sudo does mean that the admin actions of a particular user are logged, but
> unless you lock down what they can do, they can change/delete the logs
> easily enough.
>

But it seems the whole point of the thing in a multi-user environment is
that you can use a granular approach to permissions, so I suppose if you
didn't desire a particular user modifying the logs, while granting her
other administrative privileges, that would fall completely within the
purview of the philosophy and implementation of the soft that is 'sudo'.

I've never used it myself. I'm all by my lonesome on this machine. I've
been using 'su' from the very beginning (but maybe I should start or
will start whenever the future and the new 'su' arrives using 'su -').

-- 
Some years ago, when the images which this world affords first opened upon me,
when I felt the cheering warmth of summer and heard the rustling of the leaves
and the warbling of the birds, and these were all to me, I should have wept to
die; now it is my only consolation. --Mary Shelley, Frankenstein; or, The 
Modern Prometheus

Re: Please help with error message

[mick crane]

On 2018-08-07 09:18, Stephan Seitz wrote:

On Di, Aug 07, 2018 at 10:08:06 +0200, Rodolfo Medina wrote:

$ echo $PATH
/home/rodolfo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
rodolfo@sda6-acer:~$ su
Password:


You are using testing/unstable, aren’t you?

The su binary was replaced with another one, and now Debian is
breaking user space again. :-(
Now su alone doesn’t change the path but keeps the user path. You have
to use „su -”.

 The util-linux implementation of /bin/su is now used, replacing the
 one previously supplied by src:shadow (shipped in login package), and
 bringing Debian in line with other modern distributions. The two
 implementations are very similar but have some minor differences (and
 there might be more that was not yet noticed ofcourse), e.g.

 - new 'su' (with no args, i.e. when preserving the environment) also
   preserves PATH and IFS, while old su would always reset PATH and IFS
   even in 'preserve environment' mode.
 - su '' (empty user string) used to give root, but now returns an 
error.

 - previously su only had one pam config, but now 'su -' is configured
   separately in /etc/pam.d/su-l

 The first difference is probably the most user visible one. Doing
 plain 'su' is a really bad idea for many reasons, so using 'su -' is
 strongly recommended to always get a newly set up environment similar
 to a normal login. If you want to restore behaviour more similar to
 the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

Shade and sweet water!

Stephan


so where is user's path kept these days as it seems I might have set 
user PATH to root PATH ?

and I should probably put it back as it was.
mick
--
Key ID4BFEBB31

Re: As seen above: use of su vs sudo

[Martin]

Am 07.08.2018 um 13:20 schrieb The Wanderer:
> On 2018-08-07 at 05:58, Martin Drescher wrote:
> 
>> Hi members,
>>
>> I'm a little... lets say thoughtful, about the use of 'su' discussed
>> at some points in this list. I have a strong opinion about su, which
>> is, avoid it whenever it is possible and use 'sudo' instead. This is
>> the case in close to a 100% in all cases I can think of. This opinion
>> is based on how both programs work and deal with pam and
>> environmental variables. Not to forget: You will not need to share
>> (or in my case, not even set, but lock that account) a root
>> password.
>>
>> And I'm curious why Debian still prefers the use of su over sudo?
> 
> I'm not sure where you get the idea that Debian does prefer that.

It is not part of the base install. Besides the statement from Jonathan Dowland 
earlier.

> For my own machines to date (on most if not all of which I'm the primary
> if not sole user, or at least non-remote user), I don't even permit sudo
> to be installed. (Or at least I didn't, until I decided I wanted
> ubuntu-dev-tools - which depends on it - on one such machine. I may even
> revert that decision on further consideration.)

As a system operator, you need some elevated privileges on a daily basis. How 
do you do that without sudo?

> My rationale for doing that is (in crude form) that to permit any
> root-level things to be done with an ordinary user's password - even
> mediated by a task-limiting mechanism such as I understand /etc/sudoers
> to be - is a security hole; not only is an ordinary user's password more
> likely to leak (whether by social engineering or by malicious code
> running as the user or by anything in between), if you're not trusted to
> have the root password in addition to your own, you shouldn't be doing
> any root-needing things in the first place.

The point is not, that ONE person needs a root password. All people intended to 
do privileged things will have to share this password. This is a security 
nightmare!

> Over the years, I've moderated that position somewhat, enough to concede
> that there may be value in being able to hand out the ability to do some
> elevated-access things without handing out the ability to do all of
> them. That would just mean I'd want to set up various other (non-root,
> non-ordinary) users, with their own passwords and the necessary access
> to do those specific things, and hand out those passwords instead. (And

So you are spreading even more passwords around the world... No.

> still probably have people use something like 'su -c' instead of sudo,
> unless sudo permits requiring the password of a user other than the one
> invoking the command.)

Ok, you have not read the sudo man page, neither understood the concept. And 
why you do _not_ want to use 'targetpw'. No offence, but you really need to 
thin about your thesis on privilege management.


Martin 

Re: Asck some information for start to help Debian

[Ehsan Esteki]

I never riceve the answer from my email.
Can you give me please the feedabck.
Thanks.

Il giorno lun 6 ago 2018 alle ore 11:43 Ehsan Esteki
 ha scritto:
>
> Hello,
> My name is Ehsan Esteki from Italy. I would like help you to translate
> your guide and wiki in Farsi Language ( Iranian language).
> I would like how can i start to do this for you if is possible and if
> you need my help.
> I wait possibly your feedback.
> Thanks.
>
>
> --
> Ehsan Esteki



-- 
Ehsan Esteki

Re: Please help with error message

[mick crane]

On 2018-08-07 09:18, Stephan Seitz wrote:

On Di, Aug 07, 2018 at 10:08:06 +0200, Rodolfo Medina wrote:

$ echo $PATH
/home/rodolfo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
rodolfo@sda6-acer:~$ su
Password:


You are using testing/unstable, aren’t you?

The su binary was replaced with another one, and now Debian is
breaking user space again. :-(
Now su alone doesn’t change the path but keeps the user path. You have
to use „su -”.

 The util-linux implementation of /bin/su is now used, replacing the
 one previously supplied by src:shadow (shipped in login package), and
 bringing Debian in line with other modern distributions. The two
 implementations are very similar but have some minor differences (and
 there might be more that was not yet noticed ofcourse), e.g.

 - new 'su' (with no args, i.e. when preserving the environment) also
   preserves PATH and IFS, while old su would always reset PATH and IFS
   even in 'preserve environment' mode.
 - su '' (empty user string) used to give root, but now returns an 
error.

 - previously su only had one pam config, but now 'su -' is configured
   separately in /etc/pam.d/su-l

 The first difference is probably the most user visible one. Doing
 plain 'su' is a really bad idea for many reasons, so using 'su -' is
 strongly recommended to always get a newly set up environment similar
 to a normal login. If you want to restore behaviour more similar to
 the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

Shade and sweet water!

Stephan


Ah, Ok that explains why /sbin wasn't in what I thought was root's $PATH 
when su to find why ldconfig wasn't found for something or other.


cheers

mick






--
Key ID4BFEBB31

Re: As seen above: use of su vs sudo

[Martin]

> I don’t know if Debian does, but the difference between su and sudo seems 
> quite like to the difference between ssh logins with password and with keys. 
> Both have advantages and disadvantages.

By far: No.
su only invokes or acts like login, pam included. sudo may represent a complex 
role management.

It's like su calls: Let me log in as TARGET_USER, I have the password. Done.

Using sudo, you call for for a specific privilege. Which may be a command or a 
login shell, when using 'sudo -i TARGET_USER'.
sudo then decides, based on your current UID and GID, with wwhich UID and/or 
GID you want to claim what privilege, if this will be granted. And then you 
may, which is the default, type in YOUR user password to authenticate your self.

Martin

Re: New `no sound' problems

[Jude DaShiell]

On Tue, 7 Aug 2018, Rodolfo Medina wrote:

> Date: Tue, 7 Aug 2018 06:40:49
> From: Rodolfo Medina 
> To: debian-user@lists.debian.org
> Subject: Re: New `no sound' problems
> Resent-Date: Tue,  7 Aug 2018 10:41:15 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
> Rodolfo Medina  writes:
>
> > It seems to be damned recursive, the problem...  After yesterday's
> > full-upgrade in Sid, my old Acer One without sound once again...  Everything
> > seems all right: alsamixer, aumix, pulseaudio installed...  Last time this
> > happened, it was solved installing pulseaudio and alsaplayer-alsa...  Now it
> > won't...  Please help.
>
>
> Also mplayer's output seems all right:
>
> $ playfile timmy_thomas08-opportunity.wav
> MPlayer 1.3.0 (Debian), built with gcc-7 (C) 2000-2016 MPlayer Team
> do_connect: could not connect to socket
> connect: No such file or directory
> Failed to open LIRC support. You will not be able to use your remote control.
>
> Playing timmy_thomas08-opportunity.wav.
> libavformat version 58.12.100 (external)
> libavformat file format detected.
> [lavf] stream 0: audio (pcm_s16le), -aid 0
> Clip info:
>  artist: Timmy Thomas
>  comment: source: spotify
>  genre: blues
>  title: timmy_thomas08-opportunity
>  album: Why can't we live together
>  encoder: Lavf57.71.100
> Load subtitles in ./
> ==
> Opening audio decoder: [pcm] Uncompressed PCM audio decoder
> AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
> Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
> ==
> AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
> Video: no video
> Starting playback...
> A:   0.0 (00.0) of 189.0 (03:09.0) ??,?%
>
>
> but no sound at all.
>
> Rodolfo
>
Does speakertest produce any static?  I'm thinking speakertest could do
with an enhancement which would help anyone without sound tremendously.
Specifically, don't ask for sound card and device on command line at all
and cycle through everything it can find using aplay -l output.  Have
speakertest play something other than static and put a question up on the
screen after each device is tried asking the user if they can hear the
sample sound.  Once a positive response is gotten, print out on the
screen the card and device and ask the user if they'd like those stored
and a positive response would then run alsactl store.   Pulseaudio is
another problem level and has worked so poorly in the past at times here
I'm not really sure how to improve that.

>

--

Re: As seen above: use of su vs sudo

[Martin Drescher]

That

> If you set a root password in d-i (as it asks you to), it doesn't
> install sudo. If you try to set a blank root password, it locks the root
> account, installs sudo and sets up the user you created with sudo
> access.

is new to me, I never knew! And I think it is good approach. Does one actually 
get pointed to this during install?