Re: Placa de sonido

[Felipe Portales]

El domingo, 23 de septiembre de 2018 01:34:05 -03, eduardo gil escribió:
> Sigo con el temita del sonido en Linux
> 
> Tengo un precioso linux pero no tengo sonido y parece que la placa no es.
> Probé, por supuesto mil cosas que leí por ahí y nada (bueno exagero un poco
> por ahí fueron nada más que unas 800) Por aquí me recomendaron también
> recompilar el kernel cosa que no hice ¡vamos, gente! si para tener sonido
> en Linux tengo que recompilar un kernel mejor uso Windows o MAC o una
> Tablet con Android pero esa no es la idea.

Hola

Puede que sera una pregunta tonta, ¿pero estás seguro que tienes seleccionado 
el dispositivo de salida correspondiente? Cuando conecto mis audífonos USB 
tengo que cambiar la salida de la predeterminada de la laptop a los cascos.

Si estás usando salida gráfica, puedes encontrar ésto haciendo click derecho en 
el applet de sonido de tu escritorio.

Saludos

-- 
Felipe Portales
electric.velocirap...@gmx.ph

Placa de sonido

[eduardo gil]

Hola.

Sigo con el temita del sonido en Linux

Ya que me comentaron en otro post que se puede usar ALSA o PULSE y mi máquina 
tenía los dos, para evitar problemas eliminé ALSA (completamente) y dejé PULSE

Bien...

Sigo sin tener sonido. Sin embargo en el "Control de volumen de Pulse Audio" se 
ve el vumetro que funciona.

Para intentar descartar problemas de la placa de audio compre DOS tarjetas pen 
de sonido por U$S 1,5 (por eso compré dos)

Es ésta
https://www.youtube.com/watch?v=KSrtfEkpH3c 

Pues en MI máquina Linux NO funciona.

Así que probé la misma PEN en una PC Windows y en mi Notebbok MAC y las dos 
salieron andando de una, ni siquiera configuré por software nada más que la 
salida (me habrá llevado unos 15 segundos).

¡Ay! ¡Qué poblema!

Tengo un precioso linux pero no tengo sonido y parece que la placa no es.
Probé, por supuesto mil cosas que leí por ahí y nada (bueno exagero un poco por 
ahí fueron nada más que unas 800)
Por aquí me recomendaron también recompilar el kernel cosa que no hice ¡vamos, 
gente! si para tener sonido en Linux tengo que recompilar un kernel mejor uso 
Windows o MAC o una Tablet con Android pero esa no es la idea.

Aprovecho la oportunidad para recomendarles esas "placas" de sonido tipo PEN, 
son marca "pirulito" pero la verdad es que funcionan bárbaro (por lo menos en 
Windows y MAC) y son RE-baratas. NO es broma, incluso el nivel de "ruido de 
fondo" es más bajo que el de las placas integradas y la respuesta a agudos es 
mejor. Es como para tener en cuenta y quizás para tener de repuesto total 
cuestan RE-baratas U$S 1,5 (un dólar con cincuenta)

Saludos.

Re: where does fvwm get its xterm icon?

[David Wright]

On Sat 22 Sep 2018 at 07:55:12 (+0200), Nicolas George wrote:
> David Wright (2018-09-21):
> > That sounds like a different problem: a race between fvwm and the
> > xterms over which order they start in. The manner in which the race
> > affects me is that my (open) xterms get mapped all over the place
> > instead of where I want them placed. The fix is simple except that
> > the package required never made it past squeeze, so you'd need to
> > visit the archives, specifically:
> 
> The real fix is even simpler: start your X11 clients from Fvwm's
> InitFunction, not from .xinitrc.

(Actually .xsession here.) That may well be, and it does work to get
the xterms placed on the correct positions, but it also has downsides
which I can avoid while xtoolwait continues to work (even with its
bug).

1) The xterms' arguments, and (for some of them) the commands they run,
   are computed in the shell script that is ~/.xsession. While some of
   these might be simple to perform in fvwm-ese, not all of them are,
   and I'm not particularly well versed in fvwm-ese. I'm reasonably
   competent in bash dialect shell-ese however.

2) I get a log of all the .xsession operations in .xsession-errors,
   whereas the logging done by fvwm is almost all generated by the
   Echo commands I inserted.

3) There's still a race between the xterms when started from InitFunction.
   Although their placements are correct, they are mapped at their
   locations in a random order instead of deterministically. This
   randomises the PIDs and PTSs of their shells, which is less
   convenient for seeing who's running what at a glance.

Cheers,
David.

Re: can apt-daily and apt-daily-upgrade be purged from Buster?

[Ben Caradoc-Davies]

On 23/09/2018 13:12, Felix Miata wrote:

What installs/owns these systemd pseudo-programs? I want them eradicated, not
simply disabled. One or more of them by default lock package management at boot
so that I can't proceed with any of the operations that are the reason I booted.


These are provided by the "apt" package, which you should not remove as 
it is required for the normal maintenance of a Debian system. Attempting 
to remove it will result in the following dire warning:


WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt
0 upgraded, 0 newly installed, 24 to remove and 0 not upgraded.
After this operation, 261 MB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?]

I like to do all my package management manually, so I use "systemctl 
mask" to prevent these units from starting.


I use three levels of systemd prevention:

- "systemctl stop": stop a running unit.

- "systemctl disable": prevents a unit from being started by default, 
but does not prevent a unit from being started by another unit or by 
some socket witchcraft.


- "systemctl mask": prevents a unit from being started. Ever. The AK47 
of unit prevention. When you absolutely positively have to stop a unit 
from starting. (Apologies to Samuel L Jackson in "Jackie Brown".)


I think I used something like:

systemctl mask apt-daily-upgrade.timer
systemctl mask apt-daily.service
systemctl mask apt-daily.timer

Now "ls -al /etc/systemd/system" contains these:

lrwxrwxrwx  1 root root9 May  5  2017 apt-daily-upgrade.timer -> 
/dev/null

lrwxrwxrwx  1 root root9 Apr 15  2017 apt-daily.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017 apt-daily.timer -> /dev/null

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Permission issues - operator error?

[David Christensen]

On 9/22/18 5:30 PM, Richard Owlett wrote:

On 09/22/2018 03:40 PM, David Christensen wrote:

On 9/22/18 7:28 AM, Richard Owlett wrote:

On 09/22/2018 08:44 AM, Dan Purgert wrote:

Richard Owlett wrote:

I'm assuming operator problem as I get same symptoms on:
 two laptops each running different Debian releases (6.8, 9.1).
   [both using MATE desktop]
 two different media (32Gb USB flash, 240 Gb USB SSD).

Logged in as 'richard' I use Gparted (providing root password) to
repartition the drive. As I'm diagnosing problems I do a power off/on
cycle to force a cold boot.

After login in as either 'richard' or 'root' permissions are displayed
as "could not be determined".


Sounds like maybe UID issues between the installs.



I'm safe from that one on two counts.

I did the partitioning and permission steps on the same installation 
tests on the same combination of hardware and OS.


Since Squeeze I've followed the same installation routine. I allow 
login as root and answer the prompt for user the same (i.e. "Richard 
Owlett).
Once in the past I had cause to investigate UID's among installs. 
They were always the same.


Please post a console session that demonstrates what you are talking 
about.




I've spent some time today working towards that. Been going thru some 
CLI oriented tutorials. One of the problems when doing too much via GUI. 
It hides important details.


Command-line interfaces and console sessions work the best for mailing 
lists.



But if you are experiencing problems with a GUI and cannot reproduce 
them from a terminal, then you need a screen capture tool and a web 
server where you can post the pictures/ video.



David

Debugging mysterious freeze / crash

[Celejar]

Hi,

I've been experiencing a great deal of frustration recently with
intermittent freezes / crashes on my Debian Sid system (a Lenovo
W550s). The symptoms are that the screen totally freezes and the system
becomes completely unresponsive (even ssh attempts from another machine
fail), and the only thing that seems to have any effect is a hard
reboot (holding down the power button until the system restarts).

Upon reboot, I can't find anything at all interesting in 'journalctl -b
-1', or /var/log/syslog - the former just shows everything looking
normal until the moment of the crash, at which point the log just ends,
and the latter also just shows everything seeming to be fine until the
moment of the crash, and then shows the boot messages from the reboot.

Any ideas of what could be causing this, or how I could go about
debugging it? I've been using this machine for years without
experiencing anything like this, and I'm not sure for how long this has
been a problem. I did recently upgrade from stable to unstable, but I'm
not sure whether or not the problem's initial occurences coincide with
the upgrade.

Celejar

can apt-daily and apt-daily-upgrade be purged from Buster?

[Felix Miata]

What installs/owns these systemd pseudo-programs? I want them eradicated, not
simply disabled. One or more of them by default lock package management at boot
so that I can't proceed with any of the operations that are the reason I booted.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Permission issues - operator error?

[Richard Owlett]

On 09/22/2018 03:40 PM, David Christensen wrote:

On 9/22/18 7:28 AM, Richard Owlett wrote:

On 09/22/2018 08:44 AM, Dan Purgert wrote:

Richard Owlett wrote:

I'm assuming operator problem as I get same symptoms on:
 two laptops each running different Debian releases (6.8, 9.1).
   [both using MATE desktop]
 two different media (32Gb USB flash, 240 Gb USB SSD).

Logged in as 'richard' I use Gparted (providing root password) to
repartition the drive. As I'm diagnosing problems I do a power off/on
cycle to force a cold boot.

After login in as either 'richard' or 'root' permissions are displayed
as "could not be determined".


Sounds like maybe UID issues between the installs.



I'm safe from that one on two counts.

I did the partitioning and permission steps on the same installation 
tests on the same combination of hardware and OS.


Since Squeeze I've followed the same installation routine. I allow 
login as root and answer the prompt for user the same (i.e. "Richard 
Owlett).
Once in the past I had cause to investigate UID's among installs. They 
were always the same.


Please post a console session that demonstrates what you are talking about.



I've spent some time today working towards that. Been going thru some 
CLI oriented tutorials. One of the problems when doing too much via GUI. 
It hides important details.

Re: Why does Debian allow all incoming traffic by default

[mick crane]

On 2018-09-21 18:29, Subhadip Ghosh wrote:
 Debian is a Universal OS.


I wouldn't say whatever you said, doesn't make sense. I wish there
were an easier way to know about it when I started using the OS,
something to warn me that I need to configure the firewall to suit my
needs. Maybe because I came from a different OS where the defaults
were stricter, my expectations about the defaults were different.



fell foul of this years ago. installed OS, naively went on IRC while 
looking about at what was installed.

"oh, I seem to have ports open"
20 seconds later somebody took over my account"
Rapidly pulls cable and reinstalls.

Some sort of a warning during installation.
"there is no firewall running, You should probably set up some rules"

would be helpful.


mick


--
Key ID4BFEBB31

Re: [Debian-BR] Confusão com os locales

[Gilberto F da Silva]

On Sat, Sep 22, 2018 at 06:52:35PM -0400, Rodolfo wrote:
> Telegram é um sistema? Web ou Desktop?

  Desktop.
  
-- 

Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
Stela dato:2.458.384,454  Loka tempo:2018-09-22 19:53:27 Sabato   
-==-
"Algum homem primitivo um dia inventou a faca, para cortar peles e 
alimentos. Eis o cientista. Outro roubou seu invento e então o usou 
para  matar. Eis o empresário. Outro regularizou aquele roubo e os 
assassinatos. Eis o político. Outro justificou a matança dizendo 
que era  o desígnio de algum deus. Eis o religioso".
-- Francisco Saiz


signature.asc
Description: PGP signature

Re: [Debian-BR] Confusão com os locales

[Rodolfo]

Telegram é um sistema? Web ou Desktop?

Em sáb, 22 de set de 2018 às 18:51, Gilberto F da Silva
<2458...@gmail.com> escreveu:
>
> On Sat, Sep 22, 2018 at 06:39:18PM -0400, Rodolfo wrote:
> > Pelo dpkg-reconfigure você mexe no locale do terminal
> >
> > Na interface gráfica utilizei a ferramenta da mesma.
>
>   Dentro da interface gráfica, pelo emacs, estou conseguindo digitar
>   com acentuação correta. ãõéó  ĵĝŝĥŭ
>
>   No Telegram, aparecem caracteres errados. ¼¶þý
>
> --
>
> Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
> Stela dato:2.458.384,449  Loka tempo:2018-09-22 19:47:20 Sabato
> -==-
> Um homem sem religião é como um peixe sem bicicleta.

Re: [Debian-BR] Confusão com os locales

[Gilberto F da Silva]

On Sat, Sep 22, 2018 at 06:39:18PM -0400, Rodolfo wrote:
> Pelo dpkg-reconfigure você mexe no locale do terminal
> 
> Na interface gráfica utilizei a ferramenta da mesma.

  Dentro da interface gráfica, pelo emacs, estou conseguindo digitar
  com acentuação correta. ãõéó  ĵĝŝĥŭ

  No Telegram, aparecem caracteres errados. ¼¶þý
  
-- 

Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
Stela dato:2.458.384,449  Loka tempo:2018-09-22 19:47:20 Sabato   
-==-
Um homem sem religião é como um peixe sem bicicleta.


signature.asc
Description: PGP signature

Re: [Debian-BR] Confusão com os locales

[Rodolfo]

Pelo dpkg-reconfigure você mexe no locale do terminal

Na interface gráfica utilizei a ferramenta da mesma.



Em sáb, 22 de set de 2018 às 18:35, Gilberto F da Silva
<2458...@gmail.com> escreveu:
>
> On Sat, Sep 22, 2018 at 10:59:52AM -0300, Adriano Rafael Gomes wrote:
> > On Sat, Sep 22, 2018 at 10:41:16AM -0300, Gilberto F da Silva wrote:
> > >A localização do Debian está um tanto confusa aqui.
> > >
> > >No final das contas, a acentuação não funciona direito.
> >
> > Tente dpkg-reconfigure locales
>
>   Tentei.  Permanece do mesmo jeito.
>
>   Como está eu consigo acentuar em português mas a letras do esperanto
>   não aparecem corretamente.
>
> --
>
> Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
> Stela dato:2.458.384,439  Loka tempo:2018-09-22 19:32:00 Sabato
> -==-
> "A religião é ópio do povo".
> -- Karl Marx

Re: [Debian-BR] Confusão com os locales

[Gilberto F da Silva]

On Sat, Sep 22, 2018 at 10:59:52AM -0300, Adriano Rafael Gomes wrote:
> On Sat, Sep 22, 2018 at 10:41:16AM -0300, Gilberto F da Silva wrote:
> >A localização do Debian está um tanto confusa aqui.
> > 
> >No final das contas, a acentuação não funciona direito.
> 
> Tente dpkg-reconfigure locales

  Tentei.  Permanece do mesmo jeito.

  Como está eu consigo acentuar em português mas a letras do esperanto
  não aparecem corretamente. 

-- 

Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
Stela dato:2.458.384,439  Loka tempo:2018-09-22 19:32:00 Sabato   
-==-
"A religião é ópio do povo".
-- Karl Marx


signature.asc
Description: PGP signature

Re: Why does Debian allow all incoming traffic by default

[Simon Kengelbacher]

Am Samstag, den 22.09.2018, 23:58 +0200 schrieb Pascal Hambourg:
> Le 22/09/2018 à 23:35, Simon Kengelbacher a écrit :
> > Am Samstag, den 22.09.2018, 22:36 +0200 schrieb to...@tuxteam.de:
> > > On Sat, Sep 22, 2018 at 04:15:42PM -0400, Gene Heskett wrote:
> > > 
> > > > They have over the last two "upgrades" from wheezy to jessie
> > > > and on
> > > > to
> > > > stretch, totally disabled any attempts to forward x to another
> > > > machine,
> > > 
> > > Just a tip: there's "ssh -X" or better "ssh -Y" for that. Perhaps
> > > it
> > > suits your needs...
> > 
> > In this case I would prefer sshfs as "ssh -X" can be somewhat laggy
> > when you don't have a fast connection.
> 
> sshfs to run a remote shell and X programs ?
> 

no, to edit the file on your local environment

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 23:35, Simon Kengelbacher a écrit :

Am Samstag, den 22.09.2018, 22:36 +0200 schrieb to...@tuxteam.de:

On Sat, Sep 22, 2018 at 04:15:42PM -0400, Gene Heskett wrote:


They have over the last two "upgrades" from wheezy to jessie and on
to
stretch, totally disabled any attempts to forward x to another
machine,


Just a tip: there's "ssh -X" or better "ssh -Y" for that. Perhaps it
suits your needs...


In this case I would prefer sshfs as "ssh -X" can be somewhat laggy
when you don't have a fast connection.


sshfs to run a remote shell and X programs ?

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 20:27, Dan Ritter a écrit :

On Sat, Sep 22, 2018 at 04:52:40PM +0200, Pascal Hambourg wrote:


It does not matter what you entire point was, and I do not expect you to
describe a complete firewall policy. *You* exposed a supposedly default
firewall policy which I happened to find questionable, so I questioned it.


You should certainly find it questionable,


Thanks for acknowledging it.


You would not have exposed a broken firewall policy on purpose in order to
prove your point, would you ?


Wouldn't I?


I hope not.


I am explicitly describing a firewire policy for the sake of
argument, and in no way advocating it.


For the sake of argument, you should have described a sensible firewall 
policy or no one would have taken your point seriously. The policy you 
described was not sensible. Here is a common one which allows outbound 
"connections" :


- accept outbound packets and related inbound replies
- deny other inbound packets

Re: Why does Debian allow all incoming traffic by default

[Simon Kengelbacher]

Am Samstag, den 22.09.2018, 22:36 +0200 schrieb to...@tuxteam.de:
> On Sat, Sep 22, 2018 at 04:15:42PM -0400, Gene Heskett wrote:
> 
> [...]
> 
> > They have over the last two "upgrades" from wheezy to jessie and on
> > to 
> > stretch, totally disabled any attempts to forward x to another
> > machine, 
> 
> Just a tip: there's "ssh -X" or better "ssh -Y" for that. Perhaps it
> suits your needs...
> 
> Cheers
> -- tomás

In this case I would prefer sshfs as "ssh -X" can be somewhat laggy
when you don't have a fast connection. 

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 22:16, Stefan Monnier a écrit :

[...]

The benefit is that one cannot pinpoint the real attacker, of course.

Isn't the same benefit provided by just forging the source address ?

If all the routers in the path play along... but then, they are all
broken.


This condition must also be true in Reco's scenario to send the forged 
packets to the reflectors.



There's also the fact that all those RST packets can come from all over
the place and they come from where they say they come.


How can the target tell the difference ? It will receive all packets 
from its internet router anyway.



So they're a lot more difficult to block, compared to packets with
a forged source address all coming from the same IP.


"packets with a forged source address all coming from the same IP" does 
not make any sense. Packets do not "come from an IP", they just have a 
(possibly forged) source address wherever they come from.

Re: Why does Debian allow all incoming traffic by default

[Gene Heskett]

On Saturday 22 September 2018 16:36:15 to...@tuxteam.de wrote:

> On Sat, Sep 22, 2018 at 04:15:42PM -0400, Gene Heskett wrote:
>
> [...]
>
> > They have over the last two "upgrades" from wheezy to jessie and on
> > to stretch, totally disabled any attempts to forward x to another
> > machine,
>
> Just a tip: there's "ssh -X" or better "ssh -Y" for that. Perhaps it
> suits your needs...
>
> Cheers
> -- tomás

Been using -Y for years, Tomas, doesn't work for newer than wheezy.


-- 
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: Permission issues - operator error?

[David Christensen]

On 9/22/18 7:28 AM, Richard Owlett wrote:

On 09/22/2018 08:44 AM, Dan Purgert wrote:

Richard Owlett wrote:

I'm assuming operator problem as I get same symptoms on:
 two laptops each running different Debian releases (6.8, 9.1).
   [both using MATE desktop]
 two different media (32Gb USB flash, 240 Gb USB SSD).

Logged in as 'richard' I use Gparted (providing root password) to
repartition the drive. As I'm diagnosing problems I do a power off/on
cycle to force a cold boot.

After login in as either 'richard' or 'root' permissions are displayed
as "could not be determined".


Sounds like maybe UID issues between the installs.



I'm safe from that one on two counts.

I did the partitioning and permission steps on the same installation 
tests on the same combination of hardware and OS.


Since Squeeze I've followed the same installation routine. I allow login 
as root and answer the prompt for user the same (i.e. "Richard Owlett).
Once in the past I had cause to investigate UID's among installs. They 
were always the same.


Please post a console session that demonstrates what you are talking about.


David

Re: Impossible booter mode graphique ou résolution 640x340

[ajh-valmer]

On Saturday 22 September 2018 12:16:39 didier gaumet wrote:
> Des tas de raisons peuvent expliquer ton problème, entre autres une
> mise-à-jour système lors de laquelle tu as perdu un paramétrage manuel
> personnalisé que tu ne te souviens pas avoir fait et que tu aurais dû
> refaire, un paramétrage automatique qui n'a pas été reconduit parce que
> l'outil utilisé pour ça ne reconnaît plus une technologie obsolète (les
> écrans cathodiques c'est quand même vieux de nos jours), ou souffre d'un
> bug, etc...
> (je ne suis pas très calé là-dessus mais je pense que tu peux fouiller
> les docs sur VB et read-edid pour un topo sur le sujet)
> Mais dans ton cas, en caricaturant, tu utilisais un bricolage qui était
> "tombé en marche": quand cela est possible, on relie toujours un écran
> plat (c'est du numérique) à une carte graphique (c'est du numérique
> aussi) par une liaison numérique. Dans ton cas actuellement tu fais une
> double conversion numérique>analogique puis analogique>numérique, c'est
> inutile et source de problèmes.
> La présence actuelle de prises VGA sur les écrans plats n'est destinée
> qu'à leur assurer une compatibilité minimale avec des cartes graphiques
> anciennes qui n'ont qu'une sortie VGA, pour que l'acheteur ne se
> retrouve pas avec un truc inutilisable sur son vieux PC.
> Ne te complique pas la vie et utilise ce qui est prévu pour: une liaison
> numérique HDMI (ou DVI sinon) :

Effectivement :
L'interface VGA (moniteur) <=> DVI de la carte graphique dédiée ATI,
doit limiter la résolution max.

Solution provisoire trouvée, je l'ai retirée et utilisé la 
C. G. Intel de la carte mère, reconnue toute seule.
J'obtiens une bonne résolution en attendant d'acheter un nouveau 
moniteur et CG, avec ports DVI et/ou HDMI.

Sans doute, la carte Nvidia dédiée a cassé d'un coup.

À ce propos, quelles C. G. sont bien reconnues par Linux ?

Je vous tiens au courant ASAP et merci encore aux aidants.

Le "Failed to load kernel modules" au boot,
venait de modules de xserver-xorg... inutiles, 
que j'ai désinstallés par apt purge.

A. Valmer

Re: Why does Debian allow all incoming traffic by default

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Sep 22, 2018 at 04:15:42PM -0400, Gene Heskett wrote:

[...]

> They have over the last two "upgrades" from wheezy to jessie and on to 
> stretch, totally disabled any attempts to forward x to another machine, 

Just a tip: there's "ssh -X" or better "ssh -Y" for that. Perhaps it
suits your needs...

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

iEYEARECAAYFAlump78ACgkQBcgs9XrR2kaymgCdH3eBDppz4R0+AWQbYe8/ssP/
CUoAn29066dLQ3B1Go8NbhjXy/i+aPye
=simb
-END PGP SIGNATURE-

Re: Why does Debian allow all incoming traffic by default

[Stefan Monnier]

> [...]
>> >The benefit is that one cannot pinpoint the real attacker, of course.
>> Isn't the same benefit provided by just forging the source address ?
> If all the routers in the path play along... but then, they are all
> broken.

There's also the fact that all those RST packets can come from all over
the place and they come from where they say they come.
So they're a lot more difficult to block, compared to packets with
a forged source address all coming from the same IP.


Stefan

Re: Why does Debian allow all incoming traffic by default

[Gene Heskett]

On Saturday 22 September 2018 14:27:44 Dan Ritter wrote:

> On Sat, Sep 22, 2018 at 04:52:40PM +0200, Pascal Hambourg wrote:
> > Le 22/09/2018 à 13:31, Dan Ritter a écrit :
> > > On Sat, Sep 22, 2018 at 12:55:24PM +0200, Pascal Hambourg wrote:
> > > > I do not see how all this replies to my question :
> >
> > This comment was intended to Gene Heskett.
> >
> > > > Why should only TCP inbound responses be allowed ? What about
> > > > UDP-based protocols, ping replies (ICMP echo reply), ICMP error
> > > > messages, and so on ?
> > >
> > > Given that my entire point was that no firewall policy other
> > > than "configure it yourself" will work, it's really you missing
> > > the point to expect me to describe a complete firewall policy
> > > tuned to your desires.
> >
> > It does not matter what you entire point was, and I do not expect
> > you to describe a complete firewall policy. *You* exposed a
> > supposedly default firewall policy which I happened to find
> > questionable, so I questioned it.
>
> You should certainly find it questionable,
>
> > You would not have exposed a broken firewall policy on purpose in
> > order to prove your point, would you ?
>
> Wouldn't I?
>
> I am explicitly describing a firewire policy for the sake of
> argument, and in no way advocating it. In fact, the ENTIRE
> FREAKING POINT WHICH I HAVE MADE TWICE NOW is that I am *not*
> advocating it.
>
> Do not use this firewall policy. If Debian were to do the stupid
> thing of instituting a default firewall policy other than what
> it doesn't do now, I would hope for a several month long debate
> in debian-developers about what it should be.
>
> -dsr-

I would certainly hope so, AND give due consideration to just how big a 
headache any change means for the users.

Rant mode on

They have over the last two "upgrades" from wheezy to jessie and on to 
stretch, totally disabled any attempts to forward x to another machine, 
I suppose based on someones idea of security and my questions about 
fixing that pain in the arse, so it works once again, have been totally 
ignored.  They HAVE been asked, but never acknowledged with the courtesy 
of even a reply with a link to a tut.

We build (some buy) computers for us to use, and now if I want to edit 
gcode on another machine from a comfortable office chair, I am 
restricted to nano. Or going to that machine and standing at its 
operating position just to be able to use a decent editor.

That is not fun when one is 2 weeks short of his 84th, and have 2 crushed 
disc's in my lower back limiting me to not more than an hour/day. Its 
very hard to concentrate on the code when your back is screaming at you.

But someone with the power to "make it so" hides behind the word 
security, never deigning to explain it where the user public gets to 
read it. There is something drastically wrong with that picture when we 
don't get a choice, or a say in it.

/rant

-- 
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: Why does Debian allow all incoming traffic by default

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Sep 22, 2018 at 12:58:02PM +0200, Pascal Hambourg wrote:
> Le 22/09/2018 à 11:51, Reco a écrit :

[...]

> >The benefit is that one cannot pinpoint the real attacker, of course.
> 
> Isn't the same benefit provided by just forging the source address ?

If all the routers in the path play along... but then, they are all
broken.

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

iEYEARECAAYFAlumntYACgkQBcgs9XrR2kbArACfdKlCio5Ym6LIne2jjZMwpJlB
PH4An15p+eUmR5q2uIBqK/x/v9X8VH5Q
=m583
-END PGP SIGNATURE-

Re: netstat

[rhkramer]

Thanks!

On Friday, September 21, 2018 02:10:40 PM Reco wrote:
> On Fri, Sep 21, 2018 at 01:52:00PM -0400, rhkra...@gmail.com wrote:

> > What is that telling me

Re: Problema configurar wifi Debian 9

[Gilberto F da Silva]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jul 17, 2017 at 01:10:54AM +0100, Filipe yinyang wrote:
> Será que a placa de rede está desativada?
> 

  Quando o Linux não reconhece automaticamente a placa de rede, dá um
  certo trabalho para por a coisa em funcionamento.

  Basicamente é o seguinte:

  Como os comando lsusb e lspci você descobre a informação da placa de
  wireless.

  Aí você procura uma solução específica para o seu modelo de
  placa. Por sorte a distribuição Debian é a distribuição para a qual
  são feitos mais empacotamentos.

- -- 

Stela dato:2.458.384,257  Loka tempo:2018-09-22 15:09:57 Sabato   
- -==-
No fim dos tempos, os quatro Cavaleiros do Apocalipse percorrerão os 
continentes e espalharão a destruição, a dor e o ódio cantando 
música sertaneja.
-BEGIN PGP SIGNATURE-
Comment: +-+
Comment: !   Gilberto F da Silva - ICQ 136.782.571 !
Comment: !gfs1...@gmx.net - Slackware64 14.2   !
Comment: +-+

iEYEARECAAYFAlumhosACgkQJxugWtMhGw7ZJgCeNMuXpl3G4zIzuybpbEQmDrOb
7fQAn3/jaFTLThSSxuQL+5S+qF+tn6JE
=ltjb
-END PGP SIGNATURE-

Re: Why does Debian allow all incoming traffic by default

[Dan Ritter]

On Sat, Sep 22, 2018 at 04:52:40PM +0200, Pascal Hambourg wrote:
> Le 22/09/2018 à 13:31, Dan Ritter a écrit :
> > On Sat, Sep 22, 2018 at 12:55:24PM +0200, Pascal Hambourg wrote:
> > > I do not see how all this replies to my question :
> 
> This comment was intended to Gene Heskett.
> 
> > > Why should only TCP inbound responses be allowed ? What about UDP-based
> > > protocols, ping replies (ICMP echo reply), ICMP error messages, and so on 
> > > ?
> > 
> > Given that my entire point was that no firewall policy other
> > than "configure it yourself" will work, it's really you missing
> > the point to expect me to describe a complete firewall policy tuned
> > to your desires.
> 
> It does not matter what you entire point was, and I do not expect you to
> describe a complete firewall policy. *You* exposed a supposedly default
> firewall policy which I happened to find questionable, so I questioned it.

You should certainly find it questionable, 
 
> You would not have exposed a broken firewall policy on purpose in order to
> prove your point, would you ?

Wouldn't I?

I am explicitly describing a firewire policy for the sake of
argument, and in no way advocating it. In fact, the ENTIRE
FREAKING POINT WHICH I HAVE MADE TWICE NOW is that I am *not* 
advocating it.

Do not use this firewall policy. If Debian were to do the stupid
thing of instituting a default firewall policy other than what
it doesn't do now, I would hope for a several month long debate
in debian-developers about what it should be.

-dsr-

Re: ACPI BIOS ERROR

[deloptes]

steve wrote:

> Should I open a ticket in the BTS?

you have latest BIOS installed?

Re: Why does Debian allow all incoming traffic by default

[Gene Heskett]

On Saturday 22 September 2018 10:52:40 Pascal Hambourg wrote:

> Le 22/09/2018 à 13:31, Dan Ritter a écrit :
> > On Sat, Sep 22, 2018 at 12:55:24PM +0200, Pascal Hambourg wrote:
> >> I do not see how all this replies to my question :
>
> This comment was intended to Gene Heskett.
>
> >> Why should only TCP inbound responses be allowed ? What about
> >> UDP-based protocols, ping replies (ICMP echo reply), ICMP error
> >> messages, and so on ?
> >
> > Given that my entire point was that no firewall policy other
> > than "configure it yourself" will work, it's really you missing
> > the point to expect me to describe a complete firewall policy tuned
> > to your desires.
>
> It does not matter what you entire point was, and I do not expect you
> to describe a complete firewall policy. *You* exposed a supposedly
> default firewall policy which I happened to find questionable, so I
> questioned it.
>
> You would not have exposed a broken firewall policy on purpose in
> order to prove your point, would you ?

The point I was trying to make is that in close to 2 decades of my 
somewhat volatile home setup all on a 192.168.nn.nn address, and with 
the exception in my sig being the only forward in the dd-wrt rules, and 
apache2 is running in a sandbox to serve my web page, the only person to 
gain access to this network and machine was given the username and 
password to do so by me. My only problem has been someone else logging 
into one of the wifi's, which are not bridged to this net, but to the 
internet, and using up more bandwidth in a month than I do.  Still under 
my cap by quite a ways, but...

So since I don't use the radios. ATM all the radios are turned off, they 
aren't needed until one of my boys comes to visit with a smartphone and 
needs net access.

Take it for what you think its worth. It does work for me.

IMO, those without a reflashed router running dd-wrt or one of the 
work-a-likes between their machines and the internet, running all their 
machine on un-routable addresses, is a bit dumb, asking for trouble, and 
it will find them sooner rather than later unless they've built their 
own firewall.

Yes, there are $35 routers that can be updated to dd-wrt, I have such a 
netgear. But dd-wrt has stuff there is not room for in the more memory 
limited $35 model, 100% configurable port forwarding being on the 
missing list, so the netgear has logged a couple weeks when the buffalo 
got forgetfull.

Take care Pascal.

-- 
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: Iceweasel substituido por Firefox?

[Gilberto F da Silva]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jun 17, 2016 at 07:27:13AM -0300, Antonio Terceiro wrote:
> On Fri, Jun 17, 2016 at 03:58:13AM +, vitorhug...@hotmail.com wrote:
> > Depois que adotaram o system-d as coisas ficaram meio estranhas pro Debian
> 
> uma coisa não tem absolutamente nada a ver com a outra. ninguém tem
> obrigação de saber o que está acontecendo no desenvolvimento do debian,
> mas também não precisa ficar falando bobagem e espalhando FUD.

  Eu tentei desabilitar o login gráfico no Debian usando comandos do
  system-D e não funcionou.

  Tentei o comando systemctl set-default multi-user.target

- -- 

Stela dato:2.458.384,239  Loka tempo:2018-09-22 14:43:56 Sabato   
- -==-
"Sou ateu apenas porque Deus não existe. Se existisse e fosse como 
dizem as religiões, eu o odiaria!!!"
-- Mago do Verbo.
-BEGIN PGP SIGNATURE-
Comment: +-+
Comment: !   Gilberto F da Silva - ICQ 136.782.571 !
Comment: !gfs1...@gmx.net - Slackware64 14.2   !
Comment: +-+

iEYEARECAAYFAlumf8UACgkQJxugWtMhGw5lKQCfdSkMmN6ENDJ2PMNXPbd9xrAL
7EgAniQbmxP6TlCgyQYIxqV9L9aGZTNH
=QfeB
-END PGP SIGNATURE-

Re: Iceweasel substituido por Firefox?

[Gilberto F da Silva]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jun 17, 2016 at 07:30:46AM -0300, Antonio Terceiro wrote:
> On Fri, Jun 17, 2016 at 01:45:07AM -0300, Linux - Junior Polegato wrote:
> > Olá!
> > 
> > Faz meses que o firefox-esr entrou no lugar do Iceweasel no Testing, agora
> > está indo para as versões estáveis...
> > 
> > O Iceweasel existia devido há divergências entre os mantenedores do Debian
> > e a Mozilla, mas depois de 10 anos eles se entenderam e "formaram um time
> > só".
> 
> é ... não era bem isso. A mozilla tinha uma política de marcas que
> proibia distribuir binários modificados (exemplo backports de correções
> de segurança) que usassem a marca "Firefox", tanto o nome quanto o log ,
> e por isso os mantenedores no debian preciaram renomear e mudar o logo.
> 
> essa política foi alterada, e aí o nome e o logo alternativos não são
> mais necessários.

  Só vi isso acontecer no Debian.  Outras distribuições não parecem
  ter passado por isso. 

- -- 

Stela dato:2.458.384,237  Loka tempo:2018-09-22 14:41:22 Sabato   
- -==-
Dívida pra mim é sagrada. Deus lhe pague!
-BEGIN PGP SIGNATURE-
Comment: +-+
Comment: !   Gilberto F da Silva - ICQ 136.782.571 !
Comment: !gfs1...@gmx.net - Slackware64 14.2   !
Comment: +-+

iEYEARECAAYFAlumfxAACgkQJxugWtMhGw5/xgCggwEDqDUq8glg65VV8jr/qR2z
3ywAn0G89dYX4NTl7b/PewxNB5/Aamvk
=Vfjy
-END PGP SIGNATURE-

Re: PULSE & ALSA

[Galvatorix Torixgalva]

Hola,

una cosa, ahora que leo eso de los modulos.

Si tienes que compilar el kernel y no te funciona comprueba si tienes el
soporte dentro del propio kernel o lo tienes como modulo. A mi me ha pasado
que una tarjeta de sonido no me funcionaba y resulto ser que era necesario
que estuviera como modulo y no dentro del kernel. Tambien es cierto que
esto me sucedio con otro ordenador hace ya unos cuantos años xD pero te lo
digo por si acaso.

Saludos

Re: Compatibilidade do Debian

[Gilberto F da Silva]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 21, 2018 at 09:46:34AM -0300, Adriano Rafael Gomes wrote:
> On Fri, Sep 21, 2018 at 11:36:16AM +, Paulo Alexandre A. P. de Oliveira 
> wrote:
> > Alguém sabe se o Debian é compatível ou se existe alguma página acerca
> > do Debian e o Laptop Asus Zenbook ux430ua e a sua compatíbilidade com o
> > sistema?
> 
> Paulo, respondendo de forma genérica: existe um esforço para documentar como
> instalar, configurar e usar o Debian em algum hardware específico que talvez
> possa te ajudar: https://wiki.debian.org/InstallingDebianOn

  Não é a resposta que você quer.  Eu optei por comprar um computador
  que já viesse com Linux. 

- -- 

Stela dato:2.458.384,228  Loka tempo:2018-09-22 14:28:44 Sabato   
- -==-
"Sou ateu apenas porque Deus não existe. Se existisse e fosse como 
dizem as religiões, eu o odiaria!!!"
-- Mago do Verbo.
-BEGIN PGP SIGNATURE-
Comment: +-+
Comment: !   Gilberto F da Silva - ICQ 136.782.571 !
Comment: !gfs1...@gmx.net - Slackware64 14.2   !
Comment: +-+

iEYEARECAAYFAlumfCwACgkQJxugWtMhGw4TggCgymHevR5I7BZBSoOm3sPtoxtl
h9MAoICbiv58hRRZ/yBoLntqeYq27nBh
=KVqB
-END PGP SIGNATURE-

Re: sortie audio sur un netbook

[Bernard Schoenacker]

- Mail original -
> De: "Bernard Schoenacker" 
> À: "Liste Debian" 
> Envoyé: Samedi 22 Septembre 2018 18:02:37
> Objet: Re: sortie audio sur un netbook
> 
> 
bonjour,

je vérifie ce qui est chargé en module :

lsmod |grep snd
snd_hdmi_lpe_audio 24576  0
snd_soc_sst_bytcr_rt564028672  0
snd_intel_sst_acpi 16384  1
snd_intel_sst_core 40960  1 snd_intel_sst_acpi
snd_soc_rt5640 77824  2 snd_soc_sst_bytcr_rt5640
snd_soc_sst_atom_hifi2_platform65536  2 snd_intel_sst_core
snd_soc_rl6231 16384  1 snd_soc_rt5640
snd_soc_acpi   16384  2 snd_soc_sst_bytcr_rt5640,snd_intel_sst_acpi
snd_soc_acpi_intel_match16384  1 snd_intel_sst_acpi
snd_soc_core  163840  3 
snd_soc_sst_bytcr_rt5640,snd_soc_rt5640,snd_soc_sst_atom_hifi2_platform
snd_compress   20480  1 snd_soc_core
snd_pcm81920  5 
snd_soc_sst_bytcr_rt5640,snd_hdmi_lpe_audio,snd_soc_rt5640,snd_soc_sst_atom_hifi2_platform,snd_soc_core
snd_timer  28672  1 snd_pcm
snd61440  7 
snd_compress,snd_soc_sst_bytcr_rt5640,snd_hdmi_lpe_audio,snd_timer,snd_soc_sst_atom_hifi2_platform,snd_soc_core,snd_pcm
soundcore  16384  1 snd


et je n'arrive pas à trouver la solution

merci
slt
bernard

Re: [Résolu] Icedove et Lightning

[steve]

Le 22-09-2018, à 17:22:37 +0200, Norbert Ponce a écrit :


J'ai désinstaller le module lightning, puis installer le paquet
lightning de Debian. Tout est rentré dans l'ordre maintenant.



Un grand merci. Ça marche à nouveau parfaitement.


Pas de quoi. Et désolé pour le « désinstaller » :)

Re: sortie audio sur un netbook

[Bernard Schoenacker]

- Mail original -
> De: "Bernard Schoenacker" 
> À: "Liste Debian" 
> Envoyé: Samedi 22 Septembre 2018 14:43:28
> Objet: Re: sortie audio sur un netbook
> 
> - Mail original -
> > De: "Bernard Schoenacker" 
> > À: "Liste Debian" 
> > Envoyé: Vendredi 21 Septembre 2018 16:45:28
> > Objet: Re: sortie audio sur un netbook
> > 
> > 
> > 
> > - Mail original -
> > > De: "Bernard Schoenacker" 
> > > À: "Liste Debian" 
> > > Envoyé: Vendredi 21 Septembre 2018 10:23:53
> > > Objet: Re: sortie audio sur un netbook
> > > 
> > > 
> > > 
> > > - Mail original -
> > > > De: "Bernard Schoenacker" 
> > > > À: "Liste Debian" 
> > > > Envoyé: Vendredi 21 Septembre 2018 10:02:28
> > > > Objet: sortie audio sur un netbook
> > > > 
> > > > bonjour,
> > > > 
> > > > j'ai un problème de son sur le netbook et je ne trouve
> > > > pas la solution
> > > > 
> > > > lspci -nn
> > > > 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor
> > > > Z36xxx/Z37xxx Series SoC Transaction Register [8086:0f00] (rev
> > > > 0f)
> > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation
> > > > Atom
> > > > Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31]
> > > > (rev
> > > > 0f)
> > > > 00:1a.0 Encryption controller [1080]: Intel Corporation Atom
> > > > Processor Z36xxx/Z37xxx Series Trusted Execution Engine
> > > > [8086:0f18]
> > > > (rev 0f)
> > > > 00:1d.0 USB controller [0c03]: Intel Corporation Atom Processor
> > > > Z36xxx/Z37xxx Series USB EHCI [8086:0f34] (rev 0f)
> > > > 00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor
> > > > Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c] (rev 0f)
> > > > 
> > > > attention c'est indiqué hdmi, et ça me fait une belle jambe
> > > > 
> > > > pour pavucontrol : sortie factice
> > > > 
> > > > pour alsamixer j'ai :
> > > > 
> > > > 
> > > > -  (par défaut)
> > > > 0  bytcr-rt5640
> > > > 1  Intel HDMI/DP LPE Audio
> > > > 
> > > > 
> > > > /proc/asound/cards
> > > > 
> > > > 0 [bytcrrt5640]: bytcr-rt5640 - bytcr-rt5640
> > > >   bytcr-rt5640-mono-spk-in1-mic
> > > >  1 [Audio  ]: HdmiLpeAudio - Intel HDMI/DP LPE Audio
> > > >   Intel HDMI/DP LPE Audio
> > > > 
> > > > 
> > > > 
> > > > aplay -l
> > > >  Liste des Périphériques Matériels PLAYBACK 
> > > > carte 0: bytcrrt5640 [bytcr-rt5640], périphérique 0: Baytrail
> > > > Audio
> > > > (*) []
> > > >   Sous-périphériques: 1/1
> > > >   Sous-périphérique #0: subdevice #0
> > > > carte 0: bytcrrt5640 [bytcr-rt5640], périphérique 1:
> > > > Deep-Buffer
> > > > Audio (*) []
> > > >   Sous-périphériques: 1/1
> > > >   Sous-périphérique #0: subdevice #0
> > > > carte 1: Audio [Intel HDMI/DP LPE Audio], périphérique 0:
> > > > HdmiLpeAudio [Intel HDMI/DP LPE Audio]
> > > >   Sous-périphériques: 1/1
> > > >   Sous-périphérique #0: subdevice #0
> > > > carte 1: Audio [Intel HDMI/DP LPE Audio], périphérique 1:
> > > > HdmiLpeAudio [Intel HDMI/DP LPE Audio]
> > > >   Sous-périphériques: 1/1
> > > >   Sous-périphérique #0: subdevice #0
> > > > 
> > > > 
> > > > 
> > > > pour l'instant j'ai une piste :
> > > > 
> > > > https://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/bytcr-rt5640-can%27t-get-sound-to-work-4175635564/
> > > > 
> > > > ce qui est demandé ( blacklist) : snd_hdmi_lpe_audio
> > > > 
> > > > je n'ai pas compris où faut il l'indiquer
> > > > 
> > > > mais c'est à voir ...
> > > > 
> > > > merci
> > > > slt
> > > > bernard
> > > > 
> > > 
> > > 
> > > bonjour,
> > > 
> > > j'ai trouvé dans la doc, la façon de délester un module :
> > > 
> > > echo  blacklist snd_hdmi_lpe_audio
> > > >>/etc/modprobe.d/blacklist.conf
> > > 
> > > merci
> > > slt
> > > bernard
> > > 
> > 
> > bonjour,
> > 
> > et j'ai toujours pas de sortie audio tout va dans dave null
> > 
> > merci
> > slt
> > bernard
> > 
> > 
> 
> bonjour,
> 
> j'ai un peut avancé en suivant ce fil :
> 
> https://forums.linuxmint.com/viewtopic.php?f=46=208524=1115750=baytrail+audio#p1115750
> 
> et particulièrement ceci :
> 
> cp asound.state /var/lib/alsa
> 
> me donne :
> 
>  cat /var/log/kern.log  |grep Baytrail
> 
> Sep 22 13:29:26 saga kernel: [8.381355] intel_sst_acpi
> 80860F28:00: Detected Baytrail-CR platform
> Sep 22 14:13:06 saga kernel: [8.437913] intel_sst_acpi
> 80860F28:00: Detected Baytrail-CR platform
> 
> 
> journalctl -k | grep sst
> 
> sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: Detected
> Baytrail-CR platform
> sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: LPE base:
> 0x50a0 size:0x20
> sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: IRAM base:
> 0x50ac
> sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: DRAM base:
> 0x50b0
> sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: SHIM base:
> 0x50b4
> sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: Mailbox
> base: 0x50b44000
> sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: 

Re: PULSE & ALSA

[Javier Debian]

El 21/9/18 a las 17:35, eduardo gil escribió:

Pregunta simple:

¿Es necesario Pulse y ALSA o con sólo uno basta?

Vi que se instalan los dos así que por ahí convendría quitar uno.

ANTES, hace bastante tiempo, solían instalar uno solo.

Lo pregunto porque estoy teniendo problemas de sonido (no se escucha audio)

Gracias

Saludos.



Hasta Debian 7 wheezy, se usaba alsa y se podía instalar pulse, lo que 
daba no pocos dolores de cabeza.

Para jessie y stretch, con pulse alcanza y sobra.

A veces, lo que sucede, dependiendo de la tarjeta de audio, es que 
tengas que bloquear algún módulo en modprobe.


Una cosa que molesta en pulse y que era necesaria en alsa, es oss.

Si estás con jessie o stretch, mi recomendación:
Purga todo oss
Purga todo alsa
Purga todo pulse
Asegúrate que /etc/modprobe.d y /etc/modules queden "limpios" de 
configuraciones de audio.


Instala nuevamente pulse

https://wiki.debian.org/PulseAudio

JAP

[SOLVED] Re: kmail2 and TLS problem

[Hans]

Hi folks,

nice of you, to try to help. However, this isssue is already solved and should 
be marked as solved.

I updated libqt5network5 to the version in unstable and everything is workinmg 
again as it should.

So this isssue is solved. Looks like a bug in testing, fixed in unstable.

Againb, thank you very much for for all the help - ALL OF YOU!

Best regards

Hans

Re: kmail2 and TLS problem

[Martin]

Hi Hans,

is this about SMTP or IMAP/POP?
Does kmail/the server support StartTLS or SMTPS/IMAPS/POP3S?
What does nmap tell you about that thing?


Martin


Am 12.09.2018 um 09:54 schrieb Hans:
> Hi foilks,
> after last update of debian/testing I got into a problem with TLS.
> 
> I can not get access to the mail servers running TLS. Also in the settings 
> menu of kmail, I can not scan the server. Message: Server not reachable.
> 
> However, the server is reachable, as kmail-trinity is working fine.
> 
> This mail was sent via kmail-trinity.
> 
> As I do not know, if this is a bug or a local problem on my system:
> 
> Does anybody got into the same problem with actual kamil2 + debian/testing?
> 
> Thank you very much for any feedback!
> 
> Best regards
> 
> Hans 
> 

Re: [Résolu] Icedove et Lightning

[Norbert Ponce]

Le 22/09/2018 à 12:18, steve a écrit :

Le 22-09-2018, à 11:33:54 +0200, Norbert Ponce a écrit :


Bonjour,

Grosse surprise après une mise à jour de constater la disparition de 
mon agenda Lightning dans Icedove 60 avec un tas d'informations 
importantes qu'il renferme.
Je n'ai pas encore pu trouver comment charger une version 52 de 
Icedove ou de Thunderbird.
Existe-t-il un programme capable d'utiliser le fichier .ics de 
Lightning ?
Connaissez-vous un agenda "stable" pouvant gérer les évènements 
journaliers et les tâches sur une plus longue durée ?


Même problème que toi.

J'ai désinstaller le module lightning, puis installer le paquet
lightning de Debian. Tout est rentré dans l'ordre maintenant.



Un grand merci. Ça marche à nouveau parfaitement.

Re: PULSE & ALSA

[Galvatorix Torixgalva]

Hola,

el tema del sonido en linux basicamente depende de:
1) tu hardware
2) tu software
3) la configuracion del punto 2
4) que el sistema no se ponga en plan "si pero no" por el motivo X y le de
igual lo que diga el sentido comun respecto al punto 1, al punto 2 y al
punto 3.

al menos en mi caso ha funcionado asi.

Respecto a tu problema, controla que el hardware (deteccion, configuracion,
etc) esta correcto y luego el tema del volumen (esto puede ser muy
puñetero, yo tengo un monton de mandos de volumen y me costo acertar la
combinacion).

Saludos

Re: kmail2 and TLS problem

[mark]

On Wednesday, September 12, 2018 3:54:11 AM EDT Hans wrote:
> Hi foilks,
> after last update of debian/testing I got into a problem with TLS.
> 
> I can not get access to the mail servers running TLS. Also in the settings
> menu of kmail, I can not scan the server. Message: Server not reachable.
> 
> However, the server is reachable, as kmail-trinity is working fine.
> 
> This mail was sent via kmail-trinity.
> 
> As I do not know, if this is a bug or a local problem on my system:
> 
> Does anybody got into the same problem with actual kamil2 + debian/testing?
> 
> Thank you very much for any feedback!
> 
> Best regards
> 
> Hans

Hello Hans,

Is the mail server "yours"?  

If not, what do you mean that you can not get access to the mail server? 

Can you ping the mailserver?  Can you traceroute to the mailserver?  

Has the network configuration on your debian-testing box changed?

These are some preliminary questions.  Let's see where this goes?

My first guess is that there is some sort of a routing problem in your setup.  
Second guess 
is that there is a bug in debian/testing (that is why it is called testing).

Mark

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 13:11, Joe a écrit :

On Sat, 22 Sep 2018 10:38:52 +0200
Pascal Hambourg  wrote:


Le 22/09/2018 à 09:39, Joe a écrit :


Two layers of NAT work just fine, for anything but IPSec.


1) Even one single layer of NAT can cause trouble with other
applications that IPSec : FTP, SIP...


Yes, but one can reasonably expect NAT hardware to also deal with
tracking of multiple port/protocol communications. Pretty much the same
basic code does both jobs, as well as stateful firewalling.


Each complex protocol requires specific handling by both NAT and 
connection tracking. You can always work around the lack of connection 
tracking support with static firewall rules (at the cost of weaker 
security), but you cannot always work around the lack of NAT support 
with static NAT rules.



2) IPSec works through NAT, provided that you enable UDP
encapsulation aka NAT-T.


Yes, there's more to go wrong, though.


Like what ?


IPSec is commonly used to
provide pretty much fixed communication between organisations, so
terminating it on the Internet interface rather than on an internal
machine makes sense, as well as keeping it simple with just the public
IP addresses.


IPSec is also commonly used by organisations for remote access by 
travelling employees.



Other VPNs such as PPTP are more commonly used from
internal workstations. PPTP will pass through two* layers of NAT at
each end without special provision being made, apart from forwarding of
course.


PPTP does require specific NAT support for the GRE protocol.
Use case : two clients of the same PPTP server share the same public IP 
address.
The server sends a GRE packet to the public IP address. How does the NAT 
device know which client the packet must be forwarded to ?

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 13:31, Dan Ritter a écrit :

On Sat, Sep 22, 2018 at 12:55:24PM +0200, Pascal Hambourg wrote:

I do not see how all this replies to my question :


This comment was intended to Gene Heskett.


Why should only TCP inbound responses be allowed ? What about UDP-based
protocols, ping replies (ICMP echo reply), ICMP error messages, and so on ?


Given that my entire point was that no firewall policy other
than "configure it yourself" will work, it's really you missing
the point to expect me to describe a complete firewall policy tuned
to your desires.


It does not matter what you entire point was, and I do not expect you to 
describe a complete firewall policy. *You* exposed a supposedly default 
firewall policy which I happened to find questionable, so I questioned it.


You would not have exposed a broken firewall policy on purpose in order 
to prove your point, would you ?

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 15:39, Dan Purgert a écrit :

Pascal Hambourg wrote:

Le 21/09/2018 à 19:09, Dan Ritter a écrit :


Let's suppose Debian installs a basic firewall by default. How
basic? Let's say:

  - outbound: permit
  - forward: deny
  - inbound: accept NTP, DHCP, DNS, and any TCP packet which is a
response to an outbound packet


Why should unsolicited NTP, DHCP and DNS inbound packets be allowed ?


In my case, the box is running as a server for those protocols.


These services are not present *by default*. Dan Ritter talked about a 
basic firewall *by default*.



Why should only TCP inbound responses be allowed ? What about UDP-based
protocols, ping replies (ICMP echo reply), ICMP error messages, and so on ?


DNS is UDP (er, by default; though it can use TCP).  ICMP echo would
most likely fall under the "response to something outbound".


Dan Ritter did not mention "response to something outbound" but
"any *TCP* packet which is a response to an outbound packet".
ICMP echo is not TCP. I was questioning that TCP restriction.

RE: where does fvwm get its xterm icon?

[Kleene, Steven (kleenesj)]

On September 21, 2018 11:35 PM, David Wright wrote:

>> That sounds like a different problem: a race between fvwm and the
>> xterms over which order they start in. The manner in which the race
>> affects me is that my (open) xterms get mapped all over the place
>> instead of where I want them placed. The fix is simple except that
>> the package required never made it past squeeze, so you'd need to
>> visit the archives, specifically:

On Saturday, September 22, 2018 1:55 AM, Nicolas George responded:

> The real fix is even simpler: start your X11 clients from Fvwm's
> InitFunction, not from .xinitrc.

Good idea.  But I (original poster) just tried it, and once again the icon
for the xterm appeared as a live screenshot instead of smplayer.xpm, which I
had defined (for testing purposes) in ~/.fvwm/config.  Including "Test
(Init)" in the InitFunction didn't help.  Thanks.

Re: Permission issues - operator error?

[Richard Owlett]

On 09/22/2018 08:44 AM, Dan Purgert wrote:

Richard Owlett wrote:

I'm assuming operator problem as I get same symptoms on:
 two laptops each running different Debian releases (6.8, 9.1).
   [both using MATE desktop]
 two different media (32Gb USB flash, 240 Gb USB SSD).

Logged in as 'richard' I use Gparted (providing root password) to
repartition the drive. As I'm diagnosing problems I do a power off/on
cycle to force a cold boot.

After login in as either 'richard' or 'root' permissions are displayed
as "could not be determined".


Sounds like maybe UID issues between the installs.



I'm safe from that one on two counts.

I did the partitioning and permission steps on the same installation 
tests on the same combination of hardware and OS.


Since Squeeze I've followed the same installation routine. I allow login 
as root and answer the prompt for user the same (i.e. "Richard Owlett).
Once in the past I had cause to investigate UID's among installs. They 
were always the same.

Re: [Debian-BR] Confusão com os locales

[Adriano Rafael Gomes]

On Sat, Sep 22, 2018 at 10:41:16AM -0300, Gilberto F da Silva wrote:

   A localização do Debian está um tanto confusa aqui.

   No final das contas, a acentuação não funciona direito.


Tente dpkg-reconfigure locales


signature.asc
Description: PGP signature

Re: [TECH] recherche tuto facile certificat SSL Apache2

[G2PC]

Le 20/09/2018 à 21:34, Julien a écrit :
> Bonsoir,
> Tu peux regarder du côté de letsencrypt (certbot) pour générer tes
> certificats gratuits.
> Julien.
>
> Le 20 septembre 2018 20:49:19 GMT+02:00, David Pinson
>  a écrit :
>
> Bonsoir la liste,
>
> Bien que je doive rechercher sur les moteurs de recherche à ce sujet,
> j'aimerai aussi savoir si parmi vous aurait un tuto simple pour ne plus
> avoir une alerte sécurité des navigateurs web.
>
> Merci pour vos retours,
>
J'ai quasiment aboutis mon tutoriel, tu as de quoi faire, et, c'est en
français.
La partie Let's Encrypt qui t'intéresse n'est pas encore aboutie, mais,
je pense que tu auras suffisamment d'informations pour t'en sortir.
https://www.visionduweb.eu/wiki/index.php?title=Certificats_SSL_TLS_Letsencrypt

Re: Permission issues - operator error?

[Dan Purgert]

Richard Owlett wrote:
> I'm assuming operator problem as I get same symptoms on:
> two laptops each running different Debian releases (6.8, 9.1).
>   [both using MATE desktop]
> two different media (32Gb USB flash, 240 Gb USB SSD).
>
> Logged in as 'richard' I use Gparted (providing root password) to 
> repartition the drive. As I'm diagnosing problems I do a power off/on 
> cycle to force a cold boot.
>
> After login in as either 'richard' or 'root' permissions are displayed 
> as "could not be determined".

Sounds like maybe UID issues between the installs.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Relayer les alertes de sites distants

[G2PC]

Émettre un SMS, ce serait possible ?
Si quelqu'un utilise cette solution, comment est t'elle mise en place ?

Zer00CooL

[Debian-BR] Confus??o com os locales

[Gilberto F da Silva]

Saluton!

A localizao do Debian est?? um tanto confusa aqui.

Quando estou no terminal e digito locale obtenho o seguinte:

LANG=eo
LANGUAGE=
LC_CTYPE="eo"
LC_NUMERIC="eo"
LC_TIME="eo"
LC_COLLATE="eo"
LC_MONETARY="eo"
LC_MESSAGES="eo"
LC_PAPER="eo"
LC_NAME="eo"
LC_ADDRESS="eo"
LC_TELEPHONE="eo"
LC_MEASUREMENT="eo"
LC_IDENTIFICATION="eo"
LC_ALL=

Quando estou no konsole obtenho um valor bem diferente:

LANG=pt_BR.UTF-8
LANGUAGE=eo:pt_BR:pt:en_US:en_GB
LC_CTYPE="pt_BR.UTF-8"
LC_NUMERIC="pt_BR.UTF-8"
LC_TIME="pt_BR.UTF-8"
LC_COLLATE="pt_BR.UTF-8"
LC_MONETARY="pt_BR.UTF-8"
LC_MESSAGES="pt_BR.UTF-8"
LC_PAPER="pt_BR.UTF-8"
LC_NAME="pt_BR.UTF-8"
LC_ADDRESS="pt_BR.UTF-8"
LC_TELEPHONE="pt_BR.UTF-8"
LC_MEASUREMENT="pt_BR.UTF-8"
LC_IDENTIFICATION="pt_BR.UTF-8"
LC_ALL=

No final das contas, a acentuao n??o funciona direito.

-- 

Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
Stela dato:2.458.384,064  Loka tempo:2018-09-22 10:32:47 Sabato   
-==-
Um homem sem religi??o ?? como um peixe sem bicicleta.


signature.asc
Description: PGP signature

Re: Why does Debian allow all incoming traffic by default

[Dan Purgert]

Pascal Hambourg wrote:
> Le 21/09/2018 à 19:09, Dan Ritter a écrit :
>> 
>> Let's suppose Debian installs a basic firewall by default. How
>> basic? Let's say:
>> 
>>  - outbound: permit
>>  - forward: deny
>>  - inbound: accept NTP, DHCP, DNS, and any TCP packet which is a
>>response to an outbound packet
>
> Why should unsolicited NTP, DHCP and DNS inbound packets be allowed ?

In my case, the box is running as a server for those protocols.  Though,
Gene (or others) may do things differently.  NOTE -I only listen for
unsolicited requests on the LAN for those.

Only stuff on the internet is SSH and SMTP.
>
> Why should only TCP inbound responses be allowed ? What about UDP-based 
> protocols, ping replies (ICMP echo reply), ICMP error messages, and so on ?

DNS is UDP (er, by default; though it can use TCP).  ICMP echo would
most likely fall under the "response to something outbound".


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: [Debian-BR] MC navega pelos diret??rios mas n??o os torna correntes.

[Ênio Júnior]

apt-cache show mc

Em sáb, 22 de set de 2018 10:26, Gilberto F da Silva <2458...@gmail.com>
escreveu:

> On Fri, Sep 21, 2018 at 11:24:44PM -0300, Samuel Henrique wrote:
> > Ol?? Gilberto,
> >
> > >  Uso o mc para copiar/apagar/mover arquivos entre outras
> > >  coisas.  Tamb??m uso-o para navegar pelos diret??rios. No
> > >  Debian 9.5 por??m, quando saio do programa caio no
> > >  diret??rio onde fiz a chamada do mc.
> > >
> > >  Experimentei copiar os arquivos de configurao do home
> > >  do Slackware porque l?? ele funciona bem e mesmo assim o
> > >  comportamento do mc no Debian n??o mudou.
> >
> > Lendo o "Use Midnight Commander like a pro"[0] encontrei uma soluo:
> >
> > Adicione ao seu ~/.bashrc a linha:
> > alias mc='. /usr/share/mc/bin/mc-wrapper.sh'
>
>   Não lembro onde li mas já li que o Slackware não aplica patches aos
>   pacotes. No Slackware a navegação pelos diretórios funciona.  Então
>   isso significa que essa funcionalidade vem por padrão no mc.  Quem
>   empacota o programa para o Debian faz alguma coisa com que essa
>   funcionalidade deixe de funcionar por padrão.
>
>   No repositório SlackBuilds quando a gente olha algum pacote encontra
>   o email do empacotador. Resolvi com um empacotador os problemas que
>   eu tinha com o seti@home no Slackware.
>
>   Como faço para descobrir quem empacota um determinado programa para
>   o Debian?
>
> --
>
> Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
> Stela dato:2.458.384,053  Loka tempo:2018-09-22 10:16:56 Sabato
> -==-
> "Algum homem primitivo um dia inventou a faca, para cortar peles e
> alimentos. Eis o cientista. Outro roubou seu invento e então o usou
> para  matar. Eis o empresário. Outro regularizou aquele roubo e os
> assassinatos. Eis o político. Outro justificou a matança dizendo
> que era  o desígnio de algum deus. Eis o religioso".
> -- Francisco Saiz
>

Re: Why does Debian allow all incoming traffic by default

[Dan Purgert]

Reco wrote:
>   Hi.
>
> On Fri, Sep 21, 2018 at 09:59:40PM -, Dan Purgert wrote:
>> Reco wrote:
>> [...]
>> >> So this is why a wise guy buys an industrial pc for 200 US or wrt capable
>> >> router for 20-30 US installs linux and makes a good firewall then puts it
>> >> between ISP and his own network.
>> >
>> > That's one way of solving it as such measure only covers one's
>> > conventional household needs. Barely - as there's this guest Wi-Fi and
>> > that curious neighbour kid.
>> 
>> You don't firewall between your guest wifi and your trusted stuff?
>
> Personally I went as far as putting household Wi-Fi into distinct VLAN,
> and guest Wi-Fi into another one.
> The question is - can you expect that D-Link/ASUS/TPLink box to do it
> by default?

Actually with newer models that support "guest wifi", yes -- at least
insofar as between guests and "trusted".  Though not so much between the
wired and "trusted" wifi.



-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Permission issues - operator error?

[Richard Owlett]

I'm assuming operator problem as I get same symptoms on:
   two laptops each running different Debian releases (6.8, 9.1).
 [both using MATE desktop]
   two different media (32Gb USB flash, 240 Gb USB SSD).

Logged in as 'richard' I use Gparted (providing root password) to 
repartition the drive. As I'm diagnosing problems I do a power off/on 
cycle to force a cold boot.


After login in as either 'richard' or 'root' permissions are displayed 
as "could not be determined".


As 'root' I copy a directory from a random partition of the hard drive.
Permissions for the directory and its contents are displayed as 'root'.
I change the folder ownership to 'richard' clicking on apply permissions 
to enclosed files.


They enclosed directories and files are still owned by 'root' :<

Ideas?
With >50 years test/troubleshooting in various fields, do I have a blind 
spot?

(P.S. I've even written test procedures - interesting experience ;)

TIA

Re: [Debian-BR] MC navega pelos diret??rios mas n??o os torna correntes.

[Gilberto F da Silva]

On Fri, Sep 21, 2018 at 11:24:44PM -0300, Samuel Henrique wrote:
> Ol?? Gilberto,
> 
> >  Uso o mc para copiar/apagar/mover arquivos entre outras
> >  coisas.  Tamb??m uso-o para navegar pelos diret??rios. No
> >  Debian 9.5 por??m, quando saio do programa caio no
> >  diret??rio onde fiz a chamada do mc.
> >
> >  Experimentei copiar os arquivos de configurao do home
> >  do Slackware porque l?? ele funciona bem e mesmo assim o
> >  comportamento do mc no Debian n??o mudou.
> 
> Lendo o "Use Midnight Commander like a pro"[0] encontrei uma soluo:
> 
> Adicione ao seu ~/.bashrc a linha:
> alias mc='. /usr/share/mc/bin/mc-wrapper.sh'

  N??o lembro onde li mas j?? li que o Slackware n??o aplica patches aos
  pacotes. No Slackware a navegao pelos diret??rios funciona.  Ent??o
  isso significa que essa funcionalidade vem por padr??o no mc.  Quem
  empacota o programa para o Debian faz alguma coisa com que essa
  funcionalidade deixe de funcionar por padr??o.

  No reposit??rio SlackBuilds quando a gente olha algum pacote encontra
  o email do empacotador. Resolvi com um empacotador os problemas que
  eu tinha com o seti@home no Slackware.

  Como fa??o para descobrir quem empacota um determinado programa para
  o Debian?
  
-- 

Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
Stela dato:2.458.384,053  Loka tempo:2018-09-22 10:16:56 Sabato   
-==-
"Algum homem primitivo um dia inventou a faca, para cortar peles e 
alimentos. Eis o cientista. Outro roubou seu invento e ent??o o usou 
para  matar. Eis o empres??rio. Outro regularizou aquele roubo e os 
assassinatos. Eis o pol??tico. Outro justificou a matan??a dizendo 
que era  o des??gnio de algum deus. Eis o religioso".
-- Francisco Saiz


signature.asc
Description: PGP signature

Re: [Debian-BR] MC navega pelos diret??rios mas n??o os torna correntes.

[Gilberto F da Silva]

On Fri, Sep 21, 2018 at 11:24:44PM -0300, Samuel Henrique wrote:
> Ol?? Gilberto,
> 
> >  Uso o mc para copiar/apagar/mover arquivos entre outras
> >  coisas.  Tamb??m uso-o para navegar pelos diret??rios. No
> >  Debian 9.5 por??m, quando saio do programa caio no
> >  diret??rio onde fiz a chamada do mc.
> >
> >  Experimentei copiar os arquivos de configurao do home
> >  do Slackware porque l?? ele funciona bem e mesmo assim o
> >  comportamento do mc no Debian n??o mudou.
> 
> Lendo o "Use Midnight Commander like a pro"[0] encontrei uma soluo:
> 
> Adicione ao seu ~/.bashrc a linha:
> alias mc='. /usr/share/mc/bin/mc-wrapper.sh'
> 
> Se precisar para o root, tamb??m adicione no bashrc do mesmo.

  Obrigado por pesquisar e encontrar uma resposta para a minha
  quest??o.

  Procedi com o o indicado.  Funcionou dentro do console mas n??o
  funcionou no terminal virtual, aquele que a gente acessa digitando
  CTRL-ALT F#.
  
-- 

Gilberto F da Silva - gfs1...@gmx.net - ICQ 136.782.571
Stela dato:2.458.384,037  Loka tempo:2018-09-22 09:53:09 Sabato   
-==-
"Quando o primeiro espertalh??o encontrou o primeiro imbecil, nasceu 
o primeiro deus".
-- Mill??r Fernandes


signature.asc
Description: PGP signature

Re: sortie audio sur un netbook

[Bernard Schoenacker]

- Mail original -
> De: "Bernard Schoenacker" 
> À: "Liste Debian" 
> Envoyé: Vendredi 21 Septembre 2018 16:45:28
> Objet: Re: sortie audio sur un netbook
> 
> 
> 
> - Mail original -
> > De: "Bernard Schoenacker" 
> > À: "Liste Debian" 
> > Envoyé: Vendredi 21 Septembre 2018 10:23:53
> > Objet: Re: sortie audio sur un netbook
> > 
> > 
> > 
> > - Mail original -
> > > De: "Bernard Schoenacker" 
> > > À: "Liste Debian" 
> > > Envoyé: Vendredi 21 Septembre 2018 10:02:28
> > > Objet: sortie audio sur un netbook
> > > 
> > > bonjour,
> > > 
> > > j'ai un problème de son sur le netbook et je ne trouve
> > > pas la solution
> > > 
> > > lspci -nn
> > > 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor
> > > Z36xxx/Z37xxx Series SoC Transaction Register [8086:0f00] (rev
> > > 0f)
> > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom
> > > Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31]
> > > (rev
> > > 0f)
> > > 00:1a.0 Encryption controller [1080]: Intel Corporation Atom
> > > Processor Z36xxx/Z37xxx Series Trusted Execution Engine
> > > [8086:0f18]
> > > (rev 0f)
> > > 00:1d.0 USB controller [0c03]: Intel Corporation Atom Processor
> > > Z36xxx/Z37xxx Series USB EHCI [8086:0f34] (rev 0f)
> > > 00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor
> > > Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c] (rev 0f)
> > > 
> > > attention c'est indiqué hdmi, et ça me fait une belle jambe
> > > 
> > > pour pavucontrol : sortie factice
> > > 
> > > pour alsamixer j'ai :
> > > 
> > > 
> > > -  (par défaut)
> > > 0  bytcr-rt5640
> > > 1  Intel HDMI/DP LPE Audio
> > > 
> > > 
> > > /proc/asound/cards
> > > 
> > > 0 [bytcrrt5640]: bytcr-rt5640 - bytcr-rt5640
> > >   bytcr-rt5640-mono-spk-in1-mic
> > >  1 [Audio  ]: HdmiLpeAudio - Intel HDMI/DP LPE Audio
> > >   Intel HDMI/DP LPE Audio
> > > 
> > > 
> > > 
> > > aplay -l
> > >  Liste des Périphériques Matériels PLAYBACK 
> > > carte 0: bytcrrt5640 [bytcr-rt5640], périphérique 0: Baytrail
> > > Audio
> > > (*) []
> > >   Sous-périphériques: 1/1
> > >   Sous-périphérique #0: subdevice #0
> > > carte 0: bytcrrt5640 [bytcr-rt5640], périphérique 1: Deep-Buffer
> > > Audio (*) []
> > >   Sous-périphériques: 1/1
> > >   Sous-périphérique #0: subdevice #0
> > > carte 1: Audio [Intel HDMI/DP LPE Audio], périphérique 0:
> > > HdmiLpeAudio [Intel HDMI/DP LPE Audio]
> > >   Sous-périphériques: 1/1
> > >   Sous-périphérique #0: subdevice #0
> > > carte 1: Audio [Intel HDMI/DP LPE Audio], périphérique 1:
> > > HdmiLpeAudio [Intel HDMI/DP LPE Audio]
> > >   Sous-périphériques: 1/1
> > >   Sous-périphérique #0: subdevice #0
> > > 
> > > 
> > > 
> > > pour l'instant j'ai une piste :
> > > 
> > > https://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/bytcr-rt5640-can%27t-get-sound-to-work-4175635564/
> > > 
> > > ce qui est demandé ( blacklist) : snd_hdmi_lpe_audio
> > > 
> > > je n'ai pas compris où faut il l'indiquer
> > > 
> > > mais c'est à voir ...
> > > 
> > > merci
> > > slt
> > > bernard
> > > 
> > 
> > 
> > bonjour,
> > 
> > j'ai trouvé dans la doc, la façon de délester un module :
> > 
> > echo  blacklist snd_hdmi_lpe_audio >>/etc/modprobe.d/blacklist.conf
> > 
> > merci
> > slt
> > bernard
> > 
> 
> bonjour,
> 
> et j'ai toujours pas de sortie audio tout va dans dave null
> 
> merci
> slt
> bernard
> 
> 

bonjour,

j'ai un peut avancé en suivant ce fil :

https://forums.linuxmint.com/viewtopic.php?f=46=208524=1115750=baytrail+audio#p1115750

et particulièrement ceci :

cp asound.state /var/lib/alsa

me donne :

 cat /var/log/kern.log  |grep Baytrail

Sep 22 13:29:26 saga kernel: [8.381355] intel_sst_acpi 80860F28:00: 
Detected Baytrail-CR platform
Sep 22 14:13:06 saga kernel: [8.437913] intel_sst_acpi 80860F28:00: 
Detected Baytrail-CR platform


journalctl -k | grep sst

sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: Detected Baytrail-CR 
platform
sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: LPE base: 0x50a0 
size:0x20
sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: IRAM base: 0x50ac
sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: DRAM base: 0x50b0
sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: SHIM base: 0x50b4
sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: Mailbox base: 
0x50b44000
sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: DDR base: 0x2000
sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: Got drv data max 
stream 25
sept. 22 14:13:03 saga kernel: intel_sst_acpi 80860F28:00: firmware: 
direct-loading firmware intel/fw_sst_0f28.bin

find / -name fw_sst_0f28.bin
/lib/firmware/intel/fw_sst_0f28.bin

merci
slt
bernard

Re: Why does Debian allow all incoming traffic by default

[Dan Ritter]

On Sat, Sep 22, 2018 at 12:55:24PM +0200, Pascal Hambourg wrote:
> I do not see how all this replies to my question :
> 
> Why should only TCP inbound responses be allowed ? What about UDP-based
> protocols, ping replies (ICMP echo reply), ICMP error messages, and so on ?

Given that my entire point was that no firewall policy other
than "configure it yourself" will work, it's really you missing
the point to expect me to describe a complete firewall policy tuned
to your desires.

-dsr-

Re: Why does Debian allow all incoming traffic by default

[Reco]

Hi.

On Sat, Sep 22, 2018 at 12:58:02PM +0200, Pascal Hambourg wrote:
> Le 22/09/2018 à 11:51, Reco a écrit :
> > 
> > On Sat, Sep 22, 2018 at 09:46:35AM +0200, Pascal Hambourg wrote:
> > > Le 21/09/2018 à 20:32, Reco a écrit :
> > > > 
> > > > Evil person makes a TCP connection to unprotected host, but forges
> > > > source IP. Host sends TCP RST to this forged IP, host acting as a
> > > > 'reflector' to an attack. And being a bad netizen at the same time.
> > > > 
> > > > Evil person takes as many of such hosts as possible - and there goes
> > > > your old-fashioned RST DDOS.
> > > 
> > > What is the attacker's benefit over just sending packets directly to the
> > > target with forged source addresses ?
> > 
> > The benefit is that one cannot pinpoint the real attacker, of course.
> 
> Isn't the same benefit provided by just forging the source address ?

Unsure. I only have theoretical knowledge of such attacks, never
performed one myself.
Defending against the thing - that's something I'm more versed with.

Reco

Re: Why does Debian allow all incoming traffic by default

[Joe]

On Sat, 22 Sep 2018 10:38:52 +0200
Pascal Hambourg  wrote:

> Le 22/09/2018 à 09:39, Joe a écrit :
> >
> > Two layers of NAT work just fine, for anything but IPSec.  
> 
> 1) Even one single layer of NAT can cause trouble with other 
> applications that IPSec : FTP, SIP...
> 

Yes, but one can reasonably expect NAT hardware to also deal with
tracking of multiple port/protocol communications. Pretty much the same
basic code does both jobs, as well as stateful firewalling. There's a
reason that NAT is implemented by iptables rules. Only IPSec ties in
the endpoint IP addresses as well.

> 2) IPSec works through NAT, provided that you enable UDP
> encapsulation aka NAT-T.
> 
Yes, there's more to go wrong, though. IPSec is commonly used to
provide pretty much fixed communication between organisations, so
terminating it on the Internet interface rather than on an internal
machine makes sense, as well as keeping it simple with just the public
IP addresses. Other VPNs such as PPTP are more commonly used from
internal workstations. PPTP will pass through two* layers of NAT at
each end without special provision being made, apart from forwarding of
course.

*Presumably unlimited layers, but I've actually done two at each end. I
don't like commenting on any communications method until I've made it
work myself. I've had a certain amount of trouble with IPSec, though to
be fair that was in the days when most router manufacturers were still
getting the hang of connection tracking. There was plenty of early NAT
router firmware which didn't even handle PPTP well.

-- 
Joe

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 12:05, Henning Follmann a écrit :


If you send a TCP package to a computer not listening it will send a ICMP
error back.


No, standard behaviour is to send a TCP RST back.
An ICMP error may be sent back for other protocols such as UDP.

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 11:51, Reco a écrit :


On Sat, Sep 22, 2018 at 09:46:35AM +0200, Pascal Hambourg wrote:

Le 21/09/2018 à 20:32, Reco a écrit :


Evil person makes a TCP connection to unprotected host, but forges
source IP. Host sends TCP RST to this forged IP, host acting as a
'reflector' to an attack. And being a bad netizen at the same time.

Evil person takes as many of such hosts as possible - and there goes
your old-fashioned RST DDOS.


What is the attacker's benefit over just sending packets directly to the
target with forged source addresses ?


The benefit is that one cannot pinpoint the real attacker, of course.


Isn't the same benefit provided by just forging the source address ?

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 11:12, Gene Heskett a écrit :

On Saturday 22 September 2018 03:34:45 Pascal Hambourg wrote:


Le 21/09/2018 à 19:09, Dan Ritter a écrit :

Let's suppose Debian installs a basic firewall by default. How
basic? Let's say:

  - outbound: permit
  - forward: deny
  - inbound: accept NTP, DHCP, DNS, and any TCP packet which is a
response to an outbound packet


Why should unsolicited NTP, DHCP and DNS inbound packets be allowed ?


Because you can set an ntp corrected machine as a broadcaster


Does the client NTP daemon accepts inbound broadcast messages from any 
source by default ? If so, this seems quite insecure to me and the 
firewall should not allow this by default. If not, it requires some 
configuration, and allowing inbound NTP broadcast from the broadcaster 
address only should be part of this configuration.



Why should only TCP inbound responses be allowed ? What about
UDP-based protocols, ping replies (ICMP echo reply), ICMP error
messages, and so on ?


I probably should have iptables running on all my machines, but in 15
years, only one person as gotten thru dd-wrt to this machine, and I had
to give him the login credentials, I needed help configuring something,
on a long since replaced fedora install.  So there is no firewall
enabled on any of the machines here. And because everytime Andrew
Triggel sits down at a keyboard cifs dies, same for NFS, I've found that
ssh and sshfs as local networking tools Just Work, so I don't have to
putz near as much with access maintenance. No NFS shares, no sammba/cifs
shares.  And life is so much simpler.

Computers should work for you, not the other way around, forcing you to
remember how to push 17 buttons just to answer an incoming email.  This
message only required 1 button click and all this typing. Everything
else is handled automatically by scripts.


I do not see how all this replies to my question :

Why should only TCP inbound responses be allowed ? What about UDP-based 
protocols, ping replies (ICMP echo reply), ICMP error messages, and so on ?

Re: Icedove et Lightning

[didier gaumet]

Le 22/09/2018 à 11:33, Norbert Ponce a écrit :
> Bonjour,
> 
> Grosse surprise après une mise à jour de constater la disparition de mon
> agenda Lightning dans Icedove 60 avec un tas d'informations importantes
> qu'il renferme.
> Je n'ai pas encore pu trouver comment charger une version 52 de Icedove
> ou de Thunderbird.
> Existe-t-il un programme capable d'utiliser le fichier .ics de Lightning ?
> Connaissez-vous un agenda "stable" pouvant gérer les évènements
> journaliers et les tâches sur une plus longue durée ?
> 
> Merci de votre aide.
> 
> 

- avec la version 60 tu peux essayer de changer à False la valeur de
extensions.strictCompatibility dans l'éditeur de paramètres de
Thunderbird. Après avoir fermé et rouvert Thunderbird ça te ramènera
peur-être Lightning

- pour les programmes qui gèrent les .ics: Wikipedia propose une liste:
 https://en.wikipedia.org/wiki/List_of_applications_with_iCalendar_support
mais le support du format ics n'est par exemple pas suffisant pour
accéder à ton agenda Google si tu en as un. Dans ce cas-là, le plus
simple est peut-être de remplacer Thunderbird+Lightning par Evolution.

- pour Thunderbird 52, je ne suis pas encore passé automatiquement à 60
parce que apt-listbugs retient la mise-à-jour. Mais apt policy te
montrera que la version 52 est toujours disponible. Tu peux ensuite
purger la 60 et réinstaller la 52 (si c'est ce que tu souhaites), puis
marquer la 52 en hold (avec dpkg --set-selection ou aptitude) ou te
servir du pinning d'apt-preferences pour interdire sa mise-à-jour

Re: Why does Debian allow all incoming traffic by default

[Reco]

Hi.

On Sat, Sep 22, 2018 at 06:05:01AM -0400, Henning Follmann wrote:
> On Fri, Sep 21, 2018 at 09:32:45PM +0300, Reco wrote:
> > Hi.
> > 
> > On Fri, Sep 21, 2018 at 07:14:03PM +0100, Brian wrote:
> > > On Fri 21 Sep 2018 at 19:25:22 +0300, Reco wrote:
> > > 
> > > > Hi.
> > > > 
> > > > On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote:
> > > > > On Fri, Sep 21, 2018 at 08:34:50AM +0530, Subhadip Ghosh wrote:
> > > > > > Hi,
> > > > > > 
> > 
> > TCP RST attack requires exactly that. That, and an absence of a
> > firewall.
> > 
> > > There is no point with a standard Debian installation (which is what the
> > > OP inquired about). Debian is already a good netizen.
> > 
> > Good person makes a TCP connection to unprotected (as in - no firewall
> > interference) host. Since there's nothing on a host that does not listen
> > appropriate TCP port - host's kernel sends back TCP RST packet.
> > Good person's connection terminates, everyone's happy. That's how it
> > goes in your typical LAN.
> > 
> Sorry that is not how a RST attack works.
> You send a TCP package two either or both ends where the RST flag is set by
> faking your address. This way mostTCP implementation close the exsisting
> connection. The china firewall works that way. It is a kind of denial of
> service attack.

That's how it goes if you're in-between router.

> If you send a TCP package to a computer not listening it will send a ICMP
> error back.

Does not work that way for me in a single L2 segment:

nmap -sT -p 23 

tcpdump -ni 

13:28:17.826101 IP 10.20.0.1.37928 > 10.20.110.23.23: Flags [S], seq ...269
13:28:17.826111 IP 10.20.110.23.23 > 10.20.0.1.37928: Flags [R.], seq 0, ack 
...270

Can I have my ICMP packet please? I can generate those with iptables'
REJECT target, but I get TCP RST only with empty INPUT chain.


> > Evil person makes a TCP connection to unprotected host, but forges
> > source IP. Host sends TCP RST to this forged IP, host acting as a
> > 'reflector' to an attack. And being a bad netizen at the same time.
> > 
> > Evil person takes as many of such hosts as possible - and there goes
> > your old-fashioned RST DDOS.
> > 
> 
> No

Yes. Nobody does it anymore as there are numerous ways of traffic
amplification, but still 'yes'.


> > I recall that you've stated that your servers do not run any kind of
> > packet filter. So, just in case - one cannot harm the reflector that
> > way.
> > 
> 
> On those machines where I run a firewall, I use by default REJECT and not
> DROP. This also sends a ICMP back. In most cases this is desireable.

In a LAN that's definitely desirable. Helps with the troubleshooting and
stuff. Doing this in a WAN makes the host a bad netizen.


> If you
> drop the package without error the TCP sender will just think the package
> was lost and will resend the package. So in most cases REJECT might be
> better than DROP anyway.

I stopped catering for the needs of clearly broken software years ago,
so DROP for WAN is the way.

Reco

Re: Icedove et Lightning

[steve]

Le 22-09-2018, à 11:33:54 +0200, Norbert Ponce a écrit :


Bonjour,

Grosse surprise après une mise à jour de constater la disparition de 
mon agenda Lightning dans Icedove 60 avec un tas d'informations 
importantes qu'il renferme.
Je n'ai pas encore pu trouver comment charger une version 52 de 
Icedove ou de Thunderbird.

Existe-t-il un programme capable d'utiliser le fichier .ics de Lightning ?
Connaissez-vous un agenda "stable" pouvant gérer les évènements 
journaliers et les tâches sur une plus longue durée ?


Même problème que toi.

J'ai désinstaller le module lightning, puis installer le paquet
lightning de Debian. Tout est rentré dans l'ordre maintenant.

Re: Impossible booter mode graphique ou résolution 640x340

[didier gaumet]

Le 22/09/2018 à 11:10, ajh-valmer a écrit :

> Intéressant ces explications techniques des moniteurs.
> Mes 2 cartes graphiques Nvidia et AMD-ATI, mon moniteur,
> ont toujours très bien marché sous Stretch avec une résolution impeccable.
> 
> Ce serait intéressant de comprendre pourquoi la résolution de l'écran 
> est devenue si faible d'un coup, alors que je n'avais rien touché à mon 
> système. Ça aiderait pour le dépannage.
[...]

Des tas de raisons peuvent expliquer ton problème, entre autres une
mise-à-jour système lors de laquelle tu as perdu un paramétrage manuel
personnalisé que tu ne te souviens pas avoir fait et que tu aurais dû
refaire, un paramétrage automatique qui n'a pas été reconduit parce que
l'outil utilisé pour ça ne reconnaît plus une technologie obsolète (les
écrans cathodiques c'est quand même vieux de nos jours), ou souffre d'un
bug, etc...
(je ne suis pas très calé là-dessus mais je pense que tu peux fouiller
les docs sur VBE et read-edid pour un topo sur le sujet)

Mais dans ton cas, en caricaturant, tu utilisais un bricolage qui était
"tombé en marche": quand cela est possible, on relie toujours un écran
plat (c'est du numérique) à une carte graphique (c'est du numérique
aussi) par une liaison numérique. Dans ton cas actuellement tu fais une
double conversion numérique>analogique puis analogique>numérique, c'est
inutile et source de problèmes.
La présence actuelle de prises VGA sur les écrans plats n'est destinée
qu'à leur assurer une compatibilité minimale avec des cartes graphiques
anciennes qui n'ont qu'une sortie VGA, pour que l'acheteur ne se
retrouve pas avec un truc inutilisable sur son vieux PC.
Ne te complique pas la vie et utilise ce qui est prévu pour: une liaison
numérique HDMI (ou DVI sinon)

Re: Why does Debian allow all incoming traffic by default

[Henning Follmann]

On Fri, Sep 21, 2018 at 09:32:45PM +0300, Reco wrote:
>   Hi.
> 
> On Fri, Sep 21, 2018 at 07:14:03PM +0100, Brian wrote:
> > On Fri 21 Sep 2018 at 19:25:22 +0300, Reco wrote:
> > 
> > >   Hi.
> > > 
> > > On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote:
> > > > On Fri, Sep 21, 2018 at 08:34:50AM +0530, Subhadip Ghosh wrote:
> > > > > Hi,
> > > > > 
> 
> TCP RST attack requires exactly that. That, and an absence of a
> firewall.
> 
> > There is no point with a standard Debian installation (which is what the
> > OP inquired about). Debian is already a good netizen.
> 
> Good person makes a TCP connection to unprotected (as in - no firewall
> interference) host. Since there's nothing on a host that does not listen
> appropriate TCP port - host's kernel sends back TCP RST packet.
> Good person's connection terminates, everyone's happy. That's how it
> goes in your typical LAN.
> 
Sorry that is not how a RST attack works.
You send a TCP package two either or both ends where the RST flag is set by
faking your address. This way mostTCP implementation close the exsisting
connection. The china firewall works that way. It is a kind of denial of
service attack.

If you send a TCP package to a computer not listening it will send a ICMP
error back.


> Evil person makes a TCP connection to unprotected host, but forges
> source IP. Host sends TCP RST to this forged IP, host acting as a
> 'reflector' to an attack. And being a bad netizen at the same time.
> 
> Evil person takes as many of such hosts as possible - and there goes
> your old-fashioned RST DDOS.
> 

No

> I recall that you've stated that your servers do not run any kind of
> packet filter. So, just in case - one cannot harm the reflector that
> way.
> 

On those machines where I run a firewall, I use by default REJECT and not
DROP. This also sends a ICMP back. In most cases this is desireable. If you
drop the package without error the TCP sender will just think the package
was lost and will resend the package. So in most cases REJECT might be
better than DROP anyway.

> 
> So, in this regard Debian is imperfect, but at least they give you right
> tools to solve the problem (iptables suite), and do not force braindead
> firewall policies by default (like RHEL does).
> 
> Reco
> 

-H


-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: Why does Debian allow all incoming traffic by default

[Reco]

Hi.

On Sat, Sep 22, 2018 at 09:46:35AM +0200, Pascal Hambourg wrote:
> Le 21/09/2018 à 20:32, Reco a écrit :
> > 
> > Evil person makes a TCP connection to unprotected host, but forges
> > source IP. Host sends TCP RST to this forged IP, host acting as a
> > 'reflector' to an attack. And being a bad netizen at the same time.
> > 
> > Evil person takes as many of such hosts as possible - and there goes
> > your old-fashioned RST DDOS.
> 
> What is the attacker's benefit over just sending packets directly to the
> target with forged source addresses ?

The benefit is that one cannot pinpoint the real attacker, of course.

> Reflection attacks give a benefit for the attacker when the reflection
> provides some kind of amplification.

That's I agree with. Classic TCP RST flood does not offer any
amplification, that's why this kind of attack has more historic than
practical nature.

Reco

Re: Relayer les alertes de sites distants

[David Pinson]

Le 21/09/2018 à 17:05, Olivier a écrit :
> Bonjour,
>
> J'ai plusieurs réseaux sur des sites géographiques éloignés.
> Dans ces réseaux j'ai un une machine sous Debian qui émet de temps en
> temps (1 ou 2 fois par an) des alertes par mail.
>
> Jusqu'à présent, ces alertes sont envoyées via un compte GMail, plus
> ou moins dédié à cet usage: plusieurs machines disséminées sur toute
> la France utilisent ce compte pour émettre  des alertes.
>
> Malheureusement, une fois sur deux, pour ne pas dire plus, GMail
> bloque ces envois car ils sont pour lui un caractère suspect.
>
> Qui a trouvé une solution satisfaisante dans ce type de situation ?
> Comment la décrire ?
>
> J'imaginais en vrac:
>
> 1. Envoyer des SMS plutôt que des emails (mais il arrive fréquemement
> qu'une unique panne génère 20 ou 30 emails alors ...)
>
> 2. Utiliser un autre compte mail (mais lequel ?)
>
> Quels suggestions et retour d'expérience ?
>
> Slts
>
Bonjour,
Si tu as un abonnement Free à deux sous par mois, tu peux utiliser cette
méthode:
L'envoi du SMS se fait en appelant le lien suivant :
https://smsapi.free-mobile.fr/sendmsg
avec les paramètres suivants :

    user :  votre login
    pass :  XXX  votre clé d'identification générée
automatiquement par notre service
    msg :  le contenu du SMS encodé sous forme d'url (Percent-encoding)

Exemple : Envoyer le message "Hello World !" sur votre mobile :

https://smsapi.free-mobile.fr/sendmsg?user=votre_login=XXX=Hello%20World%20!


Chaque serveur enverront leur alerte différemment (situation
géographique, par exemple)dans le message.

C'est sûr qu'on risque de voir des SMS à gogo
mais en passant par une autre méthode pour les visualiser sur un PC,
c'est pour moi faisable !

-- 
Linuxement vôtre,
-- 
dptech ~ David Pinson

La route est longue mais la voie est libre !
--

  var beer = new beer();
   while (true)  {
  if (beer.empty)  {
  beer.refill();
  } else {
  beer.drink();
  }   
   }
 

Icedove et Lightning

[Norbert Ponce]

Bonjour,

Grosse surprise après une mise à jour de constater la disparition de mon 
agenda Lightning dans Icedove 60 avec un tas d'informations importantes 
qu'il renferme.
Je n'ai pas encore pu trouver comment charger une version 52 de Icedove 
ou de Thunderbird.

Existe-t-il un programme capable d'utiliser le fichier .ics de Lightning ?
Connaissez-vous un agenda "stable" pouvant gérer les évènements 
journaliers et les tâches sur une plus longue durée ?


Merci de votre aide.

Re: Why does Debian allow all incoming traffic by default

[Gene Heskett]

On Saturday 22 September 2018 03:34:45 Pascal Hambourg wrote:

> Le 21/09/2018 à 19:09, Dan Ritter a écrit :
> > Let's suppose Debian installs a basic firewall by default. How
> > basic? Let's say:
> >
> >  - outbound: permit
> >  - forward: deny
> >  - inbound: accept NTP, DHCP, DNS, and any TCP packet which is a
> >response to an outbound packet
>
> Why should unsolicited NTP, DHCP and DNS inbound packets be allowed ?
>
Because you can set an ntp corrected machine as a broadcaster, therefore 
reducing the load on the tier 2 servers such as debian maintains by 
using their pool.debian.org or the tier 1 servers at pool.ntp.org. That 
way I have 7 machines here, all synchronized to the first or 2nd tier of 
time servers on the planet. This machine is a slave to my router, it 
broadcasts to the other 6 machines, so I have all synched and well 
within a millisecond.

One could use his main machine that way.
Some routers can also serve as servers, dd-wrt installed  on a Buffalo 
NetFinity can also do this. So it has become the broadcaster to my all 
natted home network. I finally did that conversion last spring, cutting 
out the 2nd npt request traffic.

> Why should only TCP inbound responses be allowed ? What about
> UDP-based protocols, ping replies (ICMP echo reply), ICMP error
> messages, and so on ?

I probably should have iptables running on all my machines, but in 15 
years, only one person as gotten thru dd-wrt to this machine, and I had 
to give him the login credentials, I needed help configuring something, 
on a long since replaced fedora install.  So there is no firewall 
enabled on any of the machines here. And because everytime Andrew 
Triggel sits down at a keyboard cifs dies, same for NFS, I've found that 
ssh and sshfs as local networking tools Just Work, so I don't have to 
putz near as much with access maintenance. No NFS shares, no sammba/cifs 
shares.  And life is so much simpler.

Computers should work for you, not the other way around, forcing you to 
remember how to push 17 buttons just to answer an incoming email.  This 
message only required 1 button click and all this typing. Everything 
else is handled automatically by scripts.

-- 
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: Impossible booter mode graphique ou résolution 640x340

[ajh-valmer]

On Saturday 22 September 2018 08:56:37 didier gaumet wrote:
> Le 21/09/2018 à 23:19, ajh-valmer a écrit :
> > DVI (carte) <=> VGA (moniteur), écran plat récent.

> Remarque préliminaire: ce serait bien que tu répondes au bon endroit:
> lorsque tu réponds aux observations de Pierre dans une réponse au
> message de Paul, ça devient impossible à suivre... :-)

Désolé, afin de ne pas surcharger la ML,
je regroupe les réponses dans un seul mail.
Dorénavant, je répondrai mail par mail alors

Par contre, pourquoi je reçois le même mail trois fois de Bernard ?
 
> Tu utilises l'interface analogique (VGA), donc le mode d'entrée dégradé
> de ton écran plat récent: passe à une liaison numérique, HDMI de
> préférence, ou DVI.
> Le type de fonctionnement que tu utilises:
> - abaisse la résolution maximale que tu peux atteindre
> - empêche d'utiliser automatiquement la résolution native de ton écran
> (un écran LCD, contrairement à un ancien écran CRT, a une résolution
> native à laquelle il travaille bien, alors qu'un écran CRT travaille par
> interpolation sur le masque (je schématise: je ne suis pas spécialiste))
> Donc tant que tu utilises une liaison analogique VGA, tu obtiens une
> résolution plus faible que tu dois possiblement (effectivement, dans ton
> cas) en plus paramétrer. Si tu passes à une liaison numérique (HDMI,
> DVI), c'est paramétré automatiquement par défaut à la résolution native
> de l'écran.
> Note: pour autant que je sache, le paramétrage des Modelines était
> réservé aux liaisons analogiques (VGA, composite, composantes...) pour
> obtenir le meilleur affichage possible de l'écran sans le casser. De nos
> jours avec un écran plat en liaison numérique (le cas habituel, quoi),
> ça ne sert strictement à rien.

Intéressant ces explications techniques des moniteurs.
Mes 2 cartes graphiques Nvidia et AMD-ATI, mon moniteur,
ont toujours très bien marché sous Stretch avec une résolution impeccable.

Ce serait intéressant de comprendre pourquoi la résolution de l'écran 
est devenue si faible d'un coup, alors que je n'avais rien touché à mon 
système. Ça aiderait pour le dépannage.

Ceci dit, merci de ton aide, de Bernard, Nicolas, c'est sympa.
Devant m'absenter quelques jours, je testerai à mon retour,
et bien sûr ne manquerai de vous tenir au courant.

A. Valmer

Re: PULSE & ALSA

[Jorge Sanchez]

En mi caso solo uso ALSA, hasta donde sé pulse tiene algo que corregir.
alsa-utils


El vie., 21 sept. 2018 22:35, eduardo gil  escribió:

> Pregunta simple:
>
> ¿Es necesario Pulse y ALSA o con sólo uno basta?
>
> Vi que se instalan los dos así que por ahí convendría quitar uno.
>
> ANTES, hace bastante tiempo, solían instalar uno solo.
>
> Lo pregunto porque estoy teniendo problemas de sonido (no se escucha audio)
>
> Gracias
>
> Saludos.
>
>

ACPI BIOS ERROR

[steve]

Hi,

Almost sure nobody will have a solution, but for the sake of it, I'll
document it here.

dmesg | grep -i error
[0.004000] [Firmware Bug]: TSC ADJUST differs within socket(s), fixing all 
errors
[0.196456] ACPI BIOS Error (bug): Failure creating [\_SB.INTS], 
AE_ALREADY_EXISTS (20180531/dswload2-316)
[0.196461] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20180531/psobject-221)
[0.234643] ACPI BIOS Error (bug): Could not resolve [\SHAD._STA.SDS0], 
AE_NOT_FOUND (20180531/psargs-330)
[0.234647] ACPI Error: Method parse/execution failed \SHAD._STA, 
AE_NOT_FOUND (20180531/psparse-516)
[0.265882] ACPI BIOS Error (bug): Could not resolve [\SHAD._STA.SDS0], 
AE_NOT_FOUND (20180531/psargs-330)
[0.265887] ACPI Error: Method parse/execution failed \SHAD._STA, 
AE_NOT_FOUND (20180531/psparse-516)
[0.326959] ACPI BIOS Error (bug): Could not resolve [\SHAD._STA.SDS0], 
AE_NOT_FOUND (20180531/psargs-330)
[0.326959] ACPI Error: Method parse/execution failed \SHAD._STA, 
AE_NOT_FOUND (20180531/psparse-516)
[1.348312] ACPI BIOS Error (bug): Could not resolve [\SHAD._STA.SDS0], 
AE_NOT_FOUND (20180531/psargs-330)
[1.348392] ACPI Error: Method parse/execution failed \SHAD._STA, 
AE_NOT_FOUND (20180531/psparse-516)

(Not sure the first line is linked).

Should I open a ticket in the BTS?

Best

Steve

Re: [SOLVED] Re: Yet another UEFI/BIOS question

[steve]

Le 22-09-2018, à 10:07:36 +0200, Pascal Hambourg a écrit :


Le 22/09/2018 à 06:58, steve a écrit :



Because what I finally did is install a fresh Debian on another device
(using GPT) and the ACPI errors still were there.


In legacy mode (with a BIOS boot partition) or EFI mode (with an 
EFI system partition) ?


In EFI mode. The "Bios" is now fully in EFI mode and it sees all my boot
disks.


Ok. I expected (with little hope though) that the errors might have 
disappeared when booting in native EFI mode, not because you converted 
disks to GPT.


Me too, but no chance, always the same errors. I guess it's not related
to kernel (4.18 from backports) but to Bios firmware (up to date). All I
can hope now is that they correct it. Nevertheless it doesn't to affect
the system (or if it does, it's so subtil that I just can't notice it).



I used the opportunity of having another Debian to convert my sda disk
to GPT tables, and change the BIOS setting to UEFI only (just for the
sake of it). So all my disk have a GPT partition table except for the 3
ones for the RAID1 array. Not sure whether I can use the same
manipulations to convert them to GPT also. But since they work fine, I
might leave it as it is.


You can, but IMO it provides little value. GPT is useful in the 
following cases :

- disk bigger that 2 TiB


Might come sooner or later.


When it comes you'll use GPT on the new big disks. No need to convert 
the old smaller ones.


Well I did, with no problem. Now all my 8 disks have GPT partition
tables.


I think I'll do that so to have 100% GPT disks and leave the past where
it is and prepare the future. But this step worries me a bit because I
have all my personal data on one of the RAID1 and really don't want to
loose them. I think best would be to backup those data elsewhere in case
things go wrong.


1) Backup valuable data. RAID does not replace backups.


I know, but I rely on that, and I have a spare disk in case things go
the bad way. I have to put in place a procedure to do a real backup on
my freenas.

2) Hey ! This is RAID 1. You have redundancy. You can convert one disk 
at a time, and if things go wrong, you can just rebuild it.


Note however that there is a small chance that a disk cannot be 
converted to GPT as is. The GPT primary and backup partition tables 
requires a few unallocated sectors (33 for a default 128-entry table) 
at the beginning and at the end of the disk. If sectors in these areas 
are allocated to partitions, the conversion is not possible.


Well, they didn't, all went fine.

Thanks for your help !

Have a nice week-end.

Steve

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 22/09/2018 à 09:39, Joe a écrit :


Two layers of NAT work just fine, for anything but IPSec.


1) Even one single layer of NAT can cause trouble with other 
applications that IPSec : FTP, SIP...


2) IPSec works through NAT, provided that you enable UDP encapsulation 
aka NAT-T.

Re: [SOLVED] Re: Yet another UEFI/BIOS question

[Pascal Hambourg]

Le 22/09/2018 à 06:58, steve a écrit :



Because what I finally did is install a fresh Debian on another device
(using GPT) and the ACPI errors still were there.


In legacy mode (with a BIOS boot partition) or EFI mode (with an EFI 
system partition) ?


In EFI mode. The "Bios" is now fully in EFI mode and it sees all my boot
disks.


Ok. I expected (with little hope though) that the errors might have 
disappeared when booting in native EFI mode, not because you converted 
disks to GPT.



I used the opportunity of having another Debian to convert my sda disk
to GPT tables, and change the BIOS setting to UEFI only (just for the
sake of it). So all my disk have a GPT partition table except for the 3
ones for the RAID1 array. Not sure whether I can use the same
manipulations to convert them to GPT also. But since they work fine, I
might leave it as it is.


You can, but IMO it provides little value. GPT is useful in the 
following cases :

- disk bigger that 2 TiB


Might come sooner or later.


When it comes you'll use GPT on the new big disks. No need to convert 
the old smaller ones.



I think I'll do that so to have 100% GPT disks and leave the past where
it is and prepare the future. But this step worries me a bit because I
have all my personal data on one of the RAID1 and really don't want to
loose them. I think best would be to backup those data elsewhere in case
things go wrong.


1) Backup valuable data. RAID does not replace backups.

2) Hey ! This is RAID 1. You have redundancy. You can convert one disk 
at a time, and if things go wrong, you can just rebuild it.


Note however that there is a small chance that a disk cannot be 
converted to GPT as is. The GPT primary and backup partition tables 
requires a few unallocated sectors (33 for a default 128-entry table) at 
the beginning and at the end of the disk. If sectors in these areas are 
allocated to partitions, the conversion is not possible.

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 21/09/2018 à 20:32, Reco a écrit :


Evil person makes a TCP connection to unprotected host, but forges
source IP. Host sends TCP RST to this forged IP, host acting as a
'reflector' to an attack. And being a bad netizen at the same time.

Evil person takes as many of such hosts as possible - and there goes
your old-fashioned RST DDOS.


What is the attacker's benefit over just sending packets directly to the 
target with forged source addresses ?
Reflection attacks give a benefit for the attacker when the reflection 
provides some kind of amplification. One example is broadcast ping in a 
LAN : one single request packet triggers many reply packets. Another 
example is DNS amplification : a small DNS request triggers a much 
bigger DNS reply.
But TCP RST attack does not provide any amplification, as one SYN packet 
triggers one RST packet of similar length.

Re: Why does Debian allow all incoming traffic by default

[Joe]

On Fri, 21 Sep 2018 18:04:59 -0400
songbird  wrote:

> Subhadip Ghosh wrote:
> > Hi,
> >
> > I am using Debian and the recently I learned that a standard Debian 
> > installation allows all 3 types of traffics especially incoming by 
> > default. I know I can easily use iptables to tighten the rules but
> > I wanted to know the reasons behind the choice of this default
> > behaviour and if it makes the system more vulnerable? I tried
> > searching on the Internet but did not get any satisfactory
> > explanation. It will be helpful if anybody knows the answers to my
> > questions or can redirect me to a helpful document.  
> 
>   whenever i install a new system i include ufw (a firewall
> program) just to catch any funny stuff that might try to
> come through.
> 
>   the default settings seem to work well enough and i'm glad
> i don't have to relearn the terminology and rules for iptables.
> 
>   i'm sure a much better solution is to run a separate router
> as it's own layer of firewall may keep a lot of stuff out, 
> but as of yet i'm just not under attack enough to make it
> worth it.
> 

Better to do both. Two layers of NAT work just fine, for anything but
IPSec.

-- 
Joe

Re: Why does Debian allow all incoming traffic by default

[Pascal Hambourg]

Le 21/09/2018 à 19:09, Dan Ritter a écrit :


Let's suppose Debian installs a basic firewall by default. How
basic? Let's say:

 - outbound: permit
 - forward: deny
 - inbound: accept NTP, DHCP, DNS, and any TCP packet which is a
   response to an outbound packet


Why should unsolicited NTP, DHCP and DNS inbound packets be allowed ?

Why should only TCP inbound responses be allowed ? What about UDP-based 
protocols, ping replies (ICMP echo reply), ICMP error messages, and so on ?

Re: Why does Debian allow all incoming traffic by default

[Reco]

Hi.

On Fri, Sep 21, 2018 at 09:59:40PM -, Dan Purgert wrote:
> Reco wrote:
> > Hi.
> >
> > On Fri, Sep 21, 2018 at 11:18:36PM +0200, deloptes wrote:
> >> Reco wrote:
> >> 
> >> > So, in this regard Debian is imperfect, but at least they give you right
> >> > tools to solve the problem (iptables suite), and do not force braindead
> >> > firewall policies by default (like RHEL does).
> >> 
> >> So this is why a wise guy buys an industrial pc for 200 US or wrt capable
> >> router for 20-30 US installs linux and makes a good firewall then puts it
> >> between ISP and his own network.
> >
> > That's one way of solving it as such measure only covers one's
> > conventional household needs. Barely - as there's this guest Wi-Fi and
> > that curious neighbour kid.
> 
> You don't firewall between your guest wifi and your trusted stuff?

Personally I went as far as putting household Wi-Fi into distinct VLAN,
and guest Wi-Fi into another one.
The question is - can you expect that D-Link/ASUS/TPLink box to do it by 
default?

Reco

Re: Impossible booter mode graphique ou résolution 640x340

[didier gaumet]

Le 21/09/2018 à 23:19, ajh-valmer a écrit :
[...]
>> - quel type d'écran utilises-tu
> DVI (carte) <=> VGA (moniteur), écran plat récent.

Remarque préliminaire: ce serait bien que tu répondes au bon endroit:
lorsque tu réponds aux observations de Pierre dans une réponse au
message de Paul, ça devient impossible à suivre... :-)

Tu utilises l'interface analogique (VGA), donc le mode d'entrée dégradé
de ton écran plat récent: passe à une liaison numérique, HDMI de
préférence, ou DVI.
Le type de fonctionnement que tu utilises:
- abaisse la résolution maximale que tu peux atteindre
- empêche d'utiliser automatiquement la résolution native de ton écran
(un écran LCD, contrairement à un ancien écran CRT, a une résolution
native à laquelle il travaille bien, alors qu'un écran CRT travaille par
interpolation sur le masque (je schématise: je ne suis pas spécialiste))

Donc tant que tu utilises une liaison analogique VGA, tu obtiens une
résolution plus faible que tu dois possiblement (effectivement, dans ton
cas) en plus paramétrer. Si tu passes à une liaison numérique (HDMI,
DVI), c'est paramétré automatiquement par défaut à la résolution native
de l'écran.

Note: pour autant que je sache, le paramétrage des Modelines était
réservé aux liaisons analogiques (VGA, composite, composantes...) pour
obtenir le meilleur affichage possible de l'écran sans le casser. De nos
jours avec un écran plat en liaison numérique (le cas habituel, quoi),
ça ne sert strictement à rien.

Re: using a Windows 7 disk image with KVM?

[Chris]

On Fri, 21 Sep 2018 04:05:53 -0400
Gary Dale wrote:

> BTW: before making the image, I did run MergeIDE on the physical 
> machine. It is probably required since Windows hates being moved to
> new hardware.

I've also used Merge IDE with Windows XP and 2003. It's a nice tool. Do
you happen to know if there's a version that's suitable for Windows 10?

Chris

Windows bootloader (was Re: using a Windows 7 disk image with KVM?)

[Chris]

On Fri, 21 Sep 2018 18:49:43 +0500
Alexander V. Makartsev wrote:

> I always prefer to do the job with the tools that are native to OS.

Me too. Unfortunately, I wasn't able to repair the bootloader when
moving a windows 10 partition with gparted (to resize it later).
Reinstalling Windows was faster.

Chris

Re : Impossible booter mode graphique ou résolution 640x340

[nicolas . patrois]

Le 21/09/2018 18:50:19, ajh-valmer a écrit :

> Sinon, comment installer un noyau 4.17.0 ?

cheztoi > aptitude search 4.17.0|grep image
p  linux-image-4.17.0-3-686 - Linux 4.17 for older PCs
p  linux-image-4.17.0-3-686-dbg - Debug symbols for linux-image-4.17.0-3-686
i  linux-image-4.17.0-3-686-pae - Linux 4.17 for modern PCs
p  linux-image-4.17.0-3-686-pae-dbg - Debug symbols for 
linux-image-4.17.0-3-686-pae

Installe celui qui convient.
Si tu es en 64 bits, pas comme moi, tu le verras.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...