Re: Embarrassing security bug in systemd

[David Baron]

On יום רביעי, 6 בדצמבר 2017 22:52:17 IST Urs Thuermann wrote:
> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> later I was completely shocked when the machine actually rebooted...
> 
> Of course, my son doesn't have any special privileges, no entry in
> /etc/sudoers, etc.  But then I see
> 
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
> $ ls -l /bin/systemctl
> -rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
> $ dpkg -S /bin/systemctl
> systemd: /bin/systemctl
> 
> The /bin/systemctl binary is not suid root, so I assume[1] it
> communicates to systemd which then reboots the machine without
> checking what user the request comes from.
> 
> I wonder how can such a severe bug make it into a Debian stable
> distribution?  And is this just an insane default setting on Debian's
> side or is it yet another instance of brain-dead systemd behavior?
> 
> Searching the man pages I couldn't find a way to fix this.  How can
> that be stopped?
> 
> [1] Of course, this is not docuemented in systemctl(1) as usual with
> systemd.  Also, according to the man page, systemctl must be
> called with a "COMMAND" argument which /sbin/reboot doesn't do.
> Obviously, systemctl looks at the name it was called and somehow
> uses that as command.  The admin shall guess about this.
> 
> 
> urs

I find I need to use "sudo" to shutdown or reboot. That is using those 
(pseudo?) commands. Maybe their scripts check before going to sysemctl

Re: Embarrassing security bug in systemd

[Eric S Fraga]

On Wednesday,  6 Dec 2017 at 22:52, Urs Thuermann wrote:
> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.

Security issues etc. aside, I love the fact that your 10 year old is
asking such a question!
-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.4


signature.asc
Description: PGP signature

Re: Embarrassing security bug in systemd

[Eric S Fraga]

On Wednesday,  6 Dec 2017 at 20:21, Nicholas Geovanis wrote:
> As a former system admin for a university's 370/158 (yes, in the
> Jurassic), all I can say is, wow. That really wouldn't work in an
> American university (big surprise there...). None of that stuff was
> anywhere near a normal human being where I worked.

Yeah, I remember the big red button on the main console on our Amdahl
470.  Very tempting... :-) but definitely not user accessible.

-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.4


signature.asc
Description: PGP signature

Re: Embarrassing security bug in systemd

[deloptes]

Roberto C. Sánchez wrote:

> Then I upgraded, got systemd and it turns out that
> my configuration has been silently broken for a very long time.

to prevent this, keep a list with your customizations and use it as check
list after upgrade

I also see nothing wrong when someone that could press the halt button, can
also run reboot. On the other hand a lot of us decided against systemd (at
least as init daemon: there was a long discussion not that long ago here)

So here it says

$  /sbin/reboot
reboot: must be superuser.


regards

Re: BIOS Can Not Find Disk

[David Christensen]

On 12/05/17 15:18, Pascal Hambourg wrote:

Le 05/12/2017 à 06:55, David Christensen a écrit :
4.  The firmware finds the first GPT partition and file system, which 
look "right" for EFI boot images.


No.

5.  The firmware reads this file system and finds only one file, which 
it loads and runs (starting GRUB):


 /EFI/debian/grubx64.efi


No.

(If there were more than one choice, my guess is that I'd have to 
pre-select one in the CMOS setup, or perhaps have to select one from a 
menu at the end of POST?)


No.

First, a compliant UEFI firmware should look up its EFI boot variables 
and try each boot entry Boot* in the order defined in the BootOrder 
variable. The text description associated to theses entries is usually 
displayed in the EFI boot menu. If no entry is defined or works, then 
the firmware should look for a partition with the "EFI system partition" 
type GUID and look for an /EFI/Boot/bootx64.efi file (default path used 
on removable devices).


GRUB can be installed in such a path with

grub-install --removable

6.  GRUB finds the second GPT partition and file system, which looks 
"right" for GRUB, reads the file system, locates the appropriate files 
(notably /boot/grub/grub.cfg), and boots the system.


When /boot/grub is in a plain partition on the same drive as GRUB's core 
image (grubx64.efi here), the partition number is hardcoded in the core 
image.


Again -- are there any other commands I should run that readers might 
find interesting?


You can print the EFI boot variables with

efibootmgr -v


root@debian:~# efibootmgr -v
Timeout: 1 seconds
BootOrder: 0001,,000B,000D,000E
Boot* Windows Boot Manager 
HD(1,GPT,b1ed9b97-3b16-4838-8b46-3978e905fdd9,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a
Boot0001* debian 
HD(1,GPT,c89f1523-fff6-45d1-abbe-b2eaaa0216e0,0x800,0x10)/File(\EFI\debian\grubx64.efi)

Boot000B* CD/DVD Drive  BBS(CDROM,,0x0)P3: HL-DT-ST BD-RE  WH14NS40  .
Boot000D* Network Card  BBS(Network,,0x0)IBA GE Slot 00C8 v1395.
Boot000E* Hard DriveBBS(HD,,0x0)P0: INTEL SSDSC2CW060A3.


Boot -- there is no Windows drive in this machine.


Boot0001 -- corresponds to the first GPT partition on the SSD that is in 
the machine:


root@debian:~# blkid /dev/sda1
/dev/sda1: UUID="8F67-ADA4" TYPE="vfat" 
PARTUUID="c89f1523-fff6-45d1-abbe-b2eaaa0216e0"


root@debian:~# mount /dev/sda1 /mnt

root@debian:~# ls -l /mnt/EFI/debian/grubx64.efi
-rwx-- 1 root root 121856 Dec  4 20:23 /mnt/EFI/debian/grubx64.efi


Boot000B -- corresponds to my optical drive.


Boot000D -- corresponds to my network interface.


Boot000E -- corresponds to an SSD (with Debian Stretch BIOS/MBR) that 
was in the machine in the past, but was not installed when I installed 
Debian UEFI/GPT and currently is not installed.



STFW I see:

http://www.uefi.org/

http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf

2,706 pages -- that's going to take a while to read...


David

Re: USB camera.

[peter]

*   From: Reco 
*   Date: Fri, 3 Nov 2017 18:11:57 +0300
> This one does, at least right now it did with mpv.
> lsusb tells me that it's:
> 
> 058f:5608 Alcor Micro Corp

*   From: deloptes 
*   Date: Fri, 03 Nov 2017 18:04:40 +0100
> ID 0471:2036 Philips (or NXP) Webcam SPC1030NC
> 
> works very well - already ~10y in use

OK, thanks.

The local consignment shop currently has these 3 cameras in stock.

Logitech M/N: V-UH9,   P/N: 861078-0030
Logitech M/N: V-UAV36, P/N: 861200-
Logitech M/N: V-U0006, P/N: 860-000177, PID: LZ944BN

Can anyone confirm one working in Debian 9?

Thanks, ... Peter E.



-- 

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202  Pender Is.: +1 250 629 3757
http://easthope.ca/Peter.html  Bcc: peter at easthope. ca

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Wed, Dec 06, 2017 at 06:56:12PM -0500, Michael Stone wrote:
> 
> Side note: historically, people have always wanted to be able to reboot or
> shutdown the system they were sitting in front of. This led to a lot of
> really horrible solutions, like a bunch of setuid helper programs and
> one-off site specific hacks. Having this functionality standardized in one
> place is a net win for security, especially since there's also now a single
> standarized way to change the privileges.
> 
I don't necessarily disagree that having it centralized is a win.  I do,
however, think that it should have earned a mention in the release
notes.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Wed, Dec 06, 2017 at 10:48:11PM +, Brian wrote:
> On Wed 06 Dec 2017 at 22:52:17 +0100, Urs Thuermann wrote:
> 
> > Yesterday, my 10 years old son logged into my laptop running Debian
> > jessie using his account, and curiously asked if he is allowed to try
> > the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> > some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> > later I was completely shocked when the machine actually rebooted...
> > 
> > Of course, my son doesn't have any special privileges, no entry in
> > /etc/sudoers, etc.  But then I see
> 
> He is privileged because he has physical access to the machine.
> 
Not necessarily.  It is falacious to assume that someone logging in via
display manager or TTY has physical access.

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Thu, Dec 07, 2017 at 12:18:30PM +1300, Ben Caradoc-Davies wrote:
> On 07/12/17 11:30, Roberto C. Sánchez wrote:
> > I too consider this a rather serious bug.  However, I do not see any
> > evidence in the BTS [0] that such a bug has yet been reported against
> > systemd.
> 
> Not a bug. We can file this one alongside "console user has access to
> keyboard". Where did I out that CVE?
> 
Actually not.  In my case I use GDM.  I have a configuration directive
in /etc/gdm3/greeter.dconf-defaults as follows:

disable-restart-buttons=true

Since I have decided to let GDM manage graphical login and otherwise
depended on the fact that in order to reboot from a TTY or remote
session root permissions are required, I find systemd's behavior to be
buggy.

> Five seconds of Googling informed me that systemd-inhibit can be used to
> prevent shutdown. If you are absolutely sure that you want to wreck the
> well-thought-out privileges for console users, craft a polkit rule. If you
> only want to avoid accidents, install molly-guard.
> 
This is not something that I should have to Google.  I previously had a
working configuration that prevented halting or rebooting the system by
all non-root users.  Then I upgraded, got systemd and it turns out that
my configuration has been silently broken for a very long time.  The
fact that systemd does not respect conventions (i.e., must be root to
halt/reboot) or established configuration directives (i.e., in display
managers) should have at the very least been included in the release
notes.

This is the kind of nonsense that makes people dislike systemd.  The
priviliges for console users were already well thought out *BEFORE*
systemd, then systemd came along and wrecked it.  This is certainly not
the only example where systemd does something like this.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Nicholas Geovanis]

On Wed, Dec 6, 2017 at 6:49 PM, David Wright 
wrote:

> On Wed 06 Dec 2017 at 15:25:10 (-0800), James H. H. Lampert wrote:
>
> > Now, now, you walk up to the physical console on an AS/400, you're
> > not going to be able to do a PWRDWNSYS from a sign-on screen, nor
> > can do it if signed on as a user who doesn't have sufficient
> > authority to do a PWRDWNSYS. And you might be physically locked out
> > of the front panel. It's even possible that you might be physically
> > interdicted from unplugging the box, or shutting it down from the
> > circuit breaker panel.
>
> With the Cambridge University computing service in the days of the
> 370/165, the cut-off switch was high on the wall in the "cafeteria"
> area (self-service card reader and line printer) which was open to
> users 24 hours a day.


As a former system admin for a university's 370/158 (yes, in the Jurassic),
all I can
say is, wow. That really wouldn't work in an American university (big
surprise there...).
None of that stuff was anywhere near a normal human being where I worked.


> > Not every OS assumes by default that anybody with physical access to
> > the hardware also has the authority to shut it down.
>
> I didn't know we were talking about authority. One of the pastimes
> of kids in rough neighbourhoods is to pull the Engine Stop lever
> while a bus is picking up passengers.


And here they steal the conductors' keys on the subway and open the doors
in mid-trip.
So, we don't have conductors anymore, not for years. That's the American
solution.

But no one has picked-up the man's point: We deploy these machines as
servers, thousands
of them. This is desktop stuff that doesn't belong there, has no function
there. If we're going
to deploy these machines, why can't the manufacturers get a real, solid
clue about physical
security of the hardware? If the mainframes could do it 35 years ago why
can't it be done
today with smaller, discrete servers? Answer: It can be, but the
manufacturers value their
profit margin over your safety.

And, well, it must be said: An AS/400 is no mainframe, it's a miniSorry
dude ;-)

Re: Embarrassing security bug in systemd

[Dejan Jocic]

On 07-12-17, Michael Biebl wrote:
> 
> As has already been mentioned, active, local users can shutdown/reboot
> the system without requiring a password. This is intended behaviour (for
> the reasons already mentioned) and can indeed be overridden by custom
> polkit rules.
> 

Is there anywhere in Debian documentation example, or explanation how to
override anything with custom polkit rules? I could not find it, but
guess that it is possible that somehow I've missed it.



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

Re: Embarrassing security bug in systemd

[David Wright]

On Wed 06 Dec 2017 at 15:25:10 (-0800), James H. H. Lampert wrote:
> On 12/6/17, 2:53 PM, Michael Lange wrote:
> >uh, I guess you ought to have used your time to check your machine and
> >read some docs instead of figuring out how to best insult the debian
> >developers ;)
> >(scnr)
> 
> Now, now, you walk up to the physical console on an AS/400, you're
> not going to be able to do a PWRDWNSYS from a sign-on screen, nor
> can do it if signed on as a user who doesn't have sufficient
> authority to do a PWRDWNSYS. And you might be physically locked out
> of the front panel. It's even possible that you might be physically
> interdicted from unplugging the box, or shutting it down from the
> circuit breaker panel.

I can't speak for your jurisdiction, but typically you can shut down
a machine room without access to the room itself. I guess one reason
for this is that the halon fire suppression would kill you on entry.
With the Cambridge University computing service in the days of the
370/165, the cut-off switch was high on the wall in the "cafeteria"
area (self-service card reader and line printer) which was open to
users 24 hours a day.

> Not every OS assumes by default that anybody with physical access to
> the hardware also has the authority to shut it down.

I didn't know we were talking about authority. One of the pastimes
of kids in rough neighbourhoods is to pull the Engine Stop lever
while a bus is picking up passengers.

> (And likewise, accounts, including QSECOFR [the closest OS/400
> equivalent to root] can be restricted to certain physical
> terminals.)

Cheers,
David.

Re: Embarrassing security bug in systemd

[Michael Stone]

On Wed, Dec 06, 2017 at 03:25:10PM -0800, James H. H. Lampert wrote:
Now, now, you walk up to the physical console on an AS/400, you're not 
going to be able to do a PWRDWNSYS from a sign-on screen, nor can do 
it if signed on as a user who doesn't have sufficient authority to do 
a PWRDWNSYS. And you might be physically locked out of the front 
panel. It's even possible that you might be physically interdicted 
from unplugging the box, or shutting it down from the circuit breaker 
panel.


Not every OS assumes by default that anybody with physical access to 
the hardware also has the authority to shut it down.


In the extremely unlikely event that you have your debian system
configured with that level of physical access control, you can adjust 
the power/reboot permissions to suit your preferences. For most other 
users, the defaults are reasonable.


The main realistic use case of a different default is kiosk systems, 
where changing the privileges given to locally logged in users is just 
one of the steps that should be taken. In general, defaults are chosen 
to be useful for the largest set of users. 

Side note: historically, people have always wanted to be able to reboot 
or shutdown the system they were sitting in front of. This led to a lot 
of really horrible solutions, like a bunch of setuid helper programs and 
one-off site specific hacks. Having this functionality standardized in 
one place is a net win for security, especially since there's also now a 
single standarized way to change the privileges.


Mike Stone

Re: Alternativa ao Usermin para usuario alterar senha via web

[Rodolfo]

Ja que o problema era estetica vc poderia fazer um NAT que ja resolveria
sem problemas.

Em 6 de dez de 2017 16:15, "Henrique Fagundes" 
escreveu:

> Prezados,
>
> Obrigado a todos que responderam.
> Vou dizer como resolvi a questão.
>
> Decidi usar o próprio Usermin, só que, habilite o mod_proxy no meu apache
> e fiz o usuário final (cliente) chegar ao servidor pela porta 80.
>
> http://usermin.meucliente.com.br
>
> Eu estava evitando usar o Usermin porque não queria que usuário tivesse
> que acessar http://usermin.meucliente.com.br:2 (esteticamente feio).
> E também não poderia trocar a porta do Usermin para a 80, pois já tenho o
> Apache rodando nela.
>
> Daí eu me lembrei do mod_proxy do apache, e, problema resolvido.
>
> Obrigado a todos.
>
> Atenciosamente,
>
> Henrique Fagundes
> henri...@linuxadmin.com.br
> Skype: magnata-br-rj
> Linux User: 475399
>
> https://www.aprendendolinux.com
> https://www.facebook.com/AprendendoLinux
> https://youtube.com/AprendendoLinux
> https://twitter.com/AprendendoLinux
> https://telegram.me/AprendendoLinux
> __
> Participe do Grupo Aprendendo Linux
> https://groups.google.com/forum/#!forum/portal-aprendendo-linux
>
> Ou envie um e-mail para:
> portal-aprendendo-linux+subscr...@googlegroups.com
>
>  Mensagem original 
> Assunto: Re: Alternativa ao Usermin para usuario alterar senha via web
> De: Paulino Kenji Sato 
> Para: Henrique Fagundes 
> CC: Debian Brasil 
> Data: 03/12/2017 16:48
>
> Boa tarde.
>> Então, esses usuários não possuem acesso interativo com o servidor? Ou
>> seja, não possuem qualquer tipo de acesso a shell, terminal ou X11.
>>
>> Se possuírem uma shell (mesmo que não a use), pode emular uma sessão
>> telnet ou ssh via php e enviar os comandos para a troca de senha.
>> Evite soluções que precisem forçar permissões de root, como o uso de sudo
>> ou similar (além dos que já são fornecidos pelo sistema).
>>
>> Caso os usuários realmente não precisem de uma shell, como em um servidor
>> de email, pode-se migrar a base de usuários para um mais fácil de lidar
>> externamente, como LDAP, SQL, etc.
>> Usuários do samba podem trocar a senha via o windows ou outra ferramenta
>> SMB/CIFS. A senha do samba pode ser sincronizado com o do passwd/shadow.
>>
>>
>>
>> 2017-11-30 18:21 GMT-02:00 Henrique Fagundes > >:
>>
>> Prezados Colegas,
>>
>> Boa tarde e saudações "pinguianas" para todos.
>>
>> Gostaria de saber se alguém pode me indicar uma alternativa ao
>> Usermin. Preciso implementar uma forma do usuário poder alterar a
>> senha dele a partir de uma página web.
>>
>> Pode ser em php.
>>
>> Só é preciso que ele possa entrar com a senha antiga dele, colocar a
>> nova e confirmar.
>>
>> Os usuários são nativos do Linux, então basicamente o que o sistema
>> tem que fazer é um "passwd usuario".
>>
>> Alguém conhece alguma solução em PHP que faça isso?
>>
>> Ficarei muito grato se alguém puder ajudar.
>>
>> Atenciosamente,
>>
>> Henrique Fagundes
>> henri...@linuxadmin.com.br 
>> Skype: magnata-br-rj
>> Linux User: 475399
>>
>> https://www.aprendendolinux.com 
>> https://www.facebook.com/AprendendoLinux
>> 
>> https://youtube.com/AprendendoLinux
>> 
>> https://twitter.com/AprendendoLinux
>> 
>> https://telegram.me/AprendendoLinux
>> 
>> 
>> __
>> Participe do Grupo Aprendendo Linux
>> https://groups.google.com/forum/#!forum/portal-aprendendo-linux
>> 
>>
>> Ou envie um e-mail para:
>> portal-aprendendo-linux+subscr...@googlegroups.com
>> 
>>
>>
>>
>>
>> --
>> Paulino Kenji Sato
>>
>
>
>

Re: Embarrassing security bug in systemd

[David Wright]

On Wed 06 Dec 2017 at 22:52:17 (+0100), Urs Thuermann wrote:
> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> later I was completely shocked when the machine actually rebooted...

That's a lot of typing! I just type Ctrl-Alt-Backspace Ctrl-Alt-Del
to reboot, or tap the power button to shut down. I've also noticed
that I don't need to type any password to close the lid.
Presumably your son has progressed beyond mischievously holding down
the power button.

Cheers,
David.

Re: Embarrassing security bug in systemd

[Michael Biebl]

Am 06.12.2017 um 23:53 schrieb Michael Lange:
> Hi,
> 
> uh, I guess you ought to have used your time to check your machine and
> read some docs instead of figuring out how to best insult the debian
> developers ;)
> (scnr)
> 
> On 06 Dec 2017 22:52:17 +0100
> Urs Thuermann  wrote:
> 
> (...)
>> I wonder how can such a severe bug make it into a Debian stable
>> distribution?  And is this just an insane default setting on Debian's
>> side or is it yet another instance of brain-dead systemd behavior?
> 
> Maybe I am just a brain-dead loony, but personally I prefer to be able to
> shut down or reboot my system without having to type a password. If you
> do not like this behavior you might have to learn how to define
> polkit rules.

For the interested reader, see
/usr/share/polkit-1/actions/org.freedesktop.login1.policy

org.freedesktop.login1.power-off has the following defaults


  auth_admin_keep
  auth_admin_keep
  yes


As has already been mentioned, active, local users can shutdown/reboot
the system without requiring a password. This is intended behaviour (for
the reasons already mentioned) and can indeed be overridden by custom
polkit rules.


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



signature.asc
Description: OpenPGP digital signature

Re: Embarrassing security bug in systemd

[James H. H. Lampert]

On 12/6/17, 2:53 PM, Michael Lange wrote:

uh, I guess you ought to have used your time to check your machine and
read some docs instead of figuring out how to best insult the debian
developers ;)
(scnr)


Now, now, you walk up to the physical console on an AS/400, you're not 
going to be able to do a PWRDWNSYS from a sign-on screen, nor can do it 
if signed on as a user who doesn't have sufficient authority to do a 
PWRDWNSYS. And you might be physically locked out of the front panel. 
It's even possible that you might be physically interdicted from 
unplugging the box, or shutting it down from the circuit breaker panel.


Not every OS assumes by default that anybody with physical access to the 
hardware also has the authority to shut it down.


;-p

(And likewise, accounts, including QSECOFR [the closest OS/400 
equivalent to root] can be restricted to certain physical terminals.)


--
JHHL

Re: Embarrassing security bug in systemd

[Ben Caradoc-Davies]

On 07/12/17 11:30, Roberto C. Sánchez wrote:

I too consider this a rather serious bug.  However, I do not see any
evidence in the BTS [0] that such a bug has yet been reported against
systemd.


Not a bug. We can file this one alongside "console user has access to 
keyboard". Where did I out that CVE?


Five seconds of Googling informed me that systemd-inhibit can be used to 
prevent shutdown. If you are absolutely sure that you want to wreck the 
well-thought-out privileges for console users, craft a polkit rule. If 
you only want to avoid accidents, install molly-guard.


Kind regards,

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

Re: Embarrassing security bug in systemd

[Michael Lange]

Hi,

uh, I guess you ought to have used your time to check your machine and
read some docs instead of figuring out how to best insult the debian
developers ;)
(scnr)

On 06 Dec 2017 22:52:17 +0100
Urs Thuermann  wrote:

(...)
> I wonder how can such a severe bug make it into a Debian stable
> distribution?  And is this just an insane default setting on Debian's
> side or is it yet another instance of brain-dead systemd behavior?

Maybe I am just a brain-dead loony, but personally I prefer to be able to
shut down or reboot my system without having to type a password. If you
do not like this behavior you might have to learn how to define
polkit rules.

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown

Re: Embarrassing security bug in systemd

[Brian]

On Wed 06 Dec 2017 at 22:52:17 +0100, Urs Thuermann wrote:

> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> later I was completely shocked when the machine actually rebooted...
> 
> Of course, my son doesn't have any special privileges, no entry in
> /etc/sudoers, etc.  But then I see

He is privileged because he has physical access to the machine.

> 
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
> $ ls -l /bin/systemctl
> -rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
> $ dpkg -S /bin/systemctl
> systemd: /bin/systemctl
> 
> The /bin/systemctl binary is not suid root, so I assume[1] it
> communicates to systemd which then reboots the machine without
> checking what user the request comes from.
> 
> I wonder how can such a severe bug make it into a Debian stable
> distribution?  And is this just an insane default setting on Debian's
> side or is it yet another instance of brain-dead systemd behavior?

A user with physical access to the machine can press the ON/OFF switch
or pull the plug out or switch to a terminal and do CTL+ALT+DEL. Which
one of these actions is a bug in Debian?
 
> Searching the man pages I couldn't find a way to fix this.  How can
> that be stopped?

A cast-iron solution for stopping a user with physical access to a
machine from powering it off has been sought for ages.

-- 
Brian.

Re: BIOS Can Not Find Disk

[Felix Miata]

Pascal Hambourg composed on 2017-12-06 23:16 (UTC+0100):

> Felix Miata composed:

>> Nothing in that post makes it unambiguous that an MBR (MSDOS) partitioned 
>> disk
>> was not the subject of discussion.

> In the context of a GPT partitioned disk,   

 That context was missing from post you're complaining about.

> anyone else understands
> without any doubt that /dev/sda1 refers to the partition #1 defined in 
> the GPT partition table, not in the protective MBR.

>>> sda1 cannot be a type ee partition. Type ee can exist only in the MBR,
>>> and real partitions sda1, sda2... exist in the GPT table.

>>   The post Dan's quote came from, standing alone, as a whole, was confusion.
>> Absent clear indication of GPT context,

> Please read again the initial post. It contains absolutely clear 
> indication that the disk has a GPT label. 

 When the (long) entire thread is read, it eventually becomes apparent that the
OP switched back and forth between GPT and MBR.

The initial thread post was not relevant to the purpose of my post, which was
intended to clarify meaning of the thread post I replied to standing alone.
Critical in my post is it was addressing exclusively the content of the replied
to post. I wasn't writing exclusively for the benefit the OP or thread readers.
On the contrary, I was writing primarily to the mailing list archive, for those
finding it via web search and trying to understand it entirely based on what it
contained.
-- 
"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: Embarrassing security bug in systemd

[Glenn English]

On Wed, Dec 6, 2017 at 9:52 PM, Urs Thuermann  wrote:

> Of course, my son doesn't have any special privileges, no entry in
> /etc/sudoers, etc.  But then I see
>
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
> $ ls -l /bin/systemctl

Same in Buster...

--
Glenn English

Re: Embarrassing security bug in systemd

[Michael Stone]

On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote:

Yesterday, my 10 years old son logged into my laptop running Debian
jessie using his account, and curiously asked if he is allowed to try
the /sbin/reboot command.  Knowing I have a Linux system as opposed to
some crappy Win machine, I replied "sure, go ahead and try".  Seconds
later I was completely shocked when the machine actually rebooted...


It's a feature. Users at the console can reboot, on the theory that if 
someone's sitting at the laptop they could also just push the power 
button...


If they were logged in remotely, they would not be able to reboot.

Mike Stone

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote:
> Yesterday, my 10 years old son logged into my laptop running Debian
> jessie using his account, and curiously asked if he is allowed to try
> the /sbin/reboot command.  Knowing I have a Linux system as opposed to
> some crappy Win machine, I replied "sure, go ahead and try".  Seconds
> later I was completely shocked when the machine actually rebooted...
> 
I just tried this (in a VM) and was shocked to find that it works.

> Of course, my son doesn't have any special privileges, no entry in
> /etc/sudoers, etc.  But then I see
> 
> $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
> $ ls -l /bin/systemctl
> -rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
> $ dpkg -S /bin/systemctl
> systemd: /bin/systemctl
> 
Here are the other things in /sbin symlinked to systemctl:

$ ls -l /sbin/ |grep systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 halt -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 poweroff -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 reboot -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 runlevel -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 shutdown -> /bin/systemctl
lrwxrwxrwx 1 root root14 Jul  5 16:31 telinit -> /bin/systemctl

> The /bin/systemctl binary is not suid root, so I assume[1] it
> communicates to systemd which then reboots the machine without
> checking what user the request comes from.
> 
> I wonder how can such a severe bug make it into a Debian stable
> distribution?  And is this just an insane default setting on Debian's
> side or is it yet another instance of brain-dead systemd behavior?
> 
I too consider this a rather serious bug.  However, I do not see any
evidence in the BTS [0] that such a bug has yet been reported against
systemd.

> Searching the man pages I couldn't find a way to fix this.  How can
> that be stopped?
> 
I wonder the same thing.

Regards,

-Roberto

[0] https://bugs.debian.org/src:systemd

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Ben Caradoc-Davies]

On 07/12/17 10:52, Urs Thuermann wrote:

Yesterday, my 10 years old son logged into my laptop running Debian
jessie using his account, and curiously asked if he is allowed to try
the /sbin/reboot command.  Knowing I have a Linux system as opposed to
some crappy Win machine, I replied "sure, go ahead and try".  Seconds
later I was completely shocked when the machine actually rebooted...


I think that allowing a user logged in at the console to reboot the 
system is the correct behaviour for most desktops, whether via GUI or 
terminal. Special privileges have been granted to console users for as 
long as I can remember, long before systemd, because they have physical 
access to the machine. Console users typically are also permitted to 
mount, unmount, and eject removable media, and have access to audio 
devices. Special configuration is required to remove this functionality 
on kiosks, for example.


Please ask your son to try to reboot while logged remotely with ssh 
(loopback may be equivalent). I know that my local desktop permits 
passwordless shutdown while remote shutdown on another systemd machine 
requires a user password *and* that the user to be in sudoers.


Kind regards,

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

Re: BIOS Can Not Find Disk

[Pascal Hambourg]

Le 05/12/2017 à 03:33, Felix Miata a écrit :

Pascal Hambourg composed on 2017-12-05 00:41 (UTC+0100):


You're the only one bringing additional confusion.
Nobody but you talked about doing such a stupid thing as removing a type
ee partition. Dan and I only talked about removing the BIOS boot
partition sda1.


  In https://lists.debian.org/debian-user/2017/12/msg00089.html

Following is the entirety of what Dan wrote:

  "Then, to proceed, remove /dev/sda1 partition followed by grub-install?"

Nothing in that post makes it unambiguous that an MBR (MSDOS) partitioned disk
was not the subject of discussion.


In the context of a GPT partitioned disk, anyone else understands 
without any doubt that /dev/sda1 refers to the partition #1 defined in 
the GPT partition table, not in the protective MBR.



sda1 cannot be a type ee partition. Type ee can exist only in the MBR,
and real partitions sda1, sda2... exist in the GPT table.


  The post Dan's quote came from, standing alone, as a whole, was confusion.
Absent clear indication of GPT context,


Please read again the initial post. It contains absolutely clear 
indication that the disk has a GPT label.



the term "BIOS boot partition" is ambiguous.


No it is not. It has a perfecly clear definition, and even an entry in 
Wikipedia : 


 It could easily enough be construed as the 16 bytes at LBA 0 address

01BEh, which in BIOS/MSDOS partitioning context is sda1.


There is no such "BIOS boot" partition type defined in DOS/MBR partition 
types.

Embarrassing security bug in systemd

[Urs Thuermann]

Yesterday, my 10 years old son logged into my laptop running Debian
jessie using his account, and curiously asked if he is allowed to try
the /sbin/reboot command.  Knowing I have a Linux system as opposed to
some crappy Win machine, I replied "sure, go ahead and try".  Seconds
later I was completely shocked when the machine actually rebooted...

Of course, my son doesn't have any special privileges, no entry in
/etc/sudoers, etc.  But then I see

$ ls -l /sbin/reboot
lrwxrwxrwx 1 root root 14 Apr  8  2017 /sbin/reboot -> /bin/systemctl
$ ls -l /bin/systemctl
-rwxr-xr-x 1 root root 538904 Apr  8  2017 /bin/systemctl
$ dpkg -S /bin/systemctl
systemd: /bin/systemctl

The /bin/systemctl binary is not suid root, so I assume[1] it
communicates to systemd which then reboots the machine without
checking what user the request comes from.

I wonder how can such a severe bug make it into a Debian stable
distribution?  And is this just an insane default setting on Debian's
side or is it yet another instance of brain-dead systemd behavior?

Searching the man pages I couldn't find a way to fix this.  How can
that be stopped?

[1] Of course, this is not docuemented in systemctl(1) as usual with
systemd.  Also, according to the man page, systemctl must be
called with a "COMMAND" argument which /sbin/reboot doesn't do.
Obviously, systemctl looks at the name it was called and somehow
uses that as command.  The admin shall guess about this.


urs

Re: Removing old python packages installed with pip

[Urs Thuermann]

deloptes  writes:

> yes it is more or less safe - it depends how you let it install - perhaps
> there is also something under /usr/local/bin

Thanks, I'll do it then.  And yes, there are 3 binaries in
/usr/local/bin from the theano package with the same installation
date, which I will also remove.

urs

Re: Removing old python packages installed with pip

[Urs Thuermann]

Eike Lantzsch  writes:

> On Friday, December 1, 2017 3:24:47 PM -03 Urs Thuermann wrote:
> > On a machine running Debian stretch I have installed python3, which is
> > currently python3.5.  Nothing of python3.4 is present.
> > 
> > But in /usr/local/lib/python3.4/dist-packages/ a number of packages is
> > still installed.  Probably, these have been installed using pip3 when
> > python3.4 was current.
> > 
> > Now, it seems pip3 isn't able to remove packages from that old
> > directory.  Is it safe to just rm -r /usr/local/lib/python3.4?

> If those packages were installed together with the Debian system then 
> deinstall with aptitude or apt remove.

No, as I said, it was (most probably) installed using pip3 when
python3.4 was current in Debian.  Debian packagement doesn't know
about it, so cannot uninstall it.

> If you mix two different package installers the consequence is that one does 
> not know about the other and they can interfere with each other.

No, nothing is mixed.  pip installs in /usr/local, Debian packagement
installs in /usr.

But pip3 formerly installed in /usr/local/lib/python3.4 but now seems
not to know about anymore.  Now it installs in /usr/local/lib/python3.5.
Therefore, pip3 doesn't list and cannot uninstall python packages from
the older /usr/local/lib/python3.4.  Also, python3, which is 3.5
currently, seems not to search that old directory.

I am almost sure that just removing it will be fine, but I wanted to
make sure, that no file of pip3 e.g. in /var or elsewhere still refers
to /usr/local/lib/python3.4.  That's why I asked here.

> On Debian always install packages the "Debian way".

There are Python packages like theano and keras that are not in
Debian.  They can only be installed completely manually or using
pip3.  In both cases they go to /usr/local, of course.

urs

Re: Boot et RAID5

[Pascal Hambourg]

Le 06/12/2017 à 10:53, Daniel Caillibaud a écrit :

Le 05/12/17 à 20:36, Pascal Hambourg  a écrit :
PH> Le 05/12/2017 à 11:09, Daniel Caillibaud a écrit :
PH> > Le 05/12/17 à 00:23, Pascal Hambourg  a écrit :
PH> > PH> (1,5 fois plus, la belle affaire),
PH> >
PH> > Je penses que c'est bien ×3 si tu donnes au noyau 3 partitions de swap 
sur 3 disques
PH> > différents, en tout cas avec 2 disques j'avais effectivement mesuré du ×2 
en lecture et
PH> > écriture.
PH>
PH> Peux-tu expliquer comment tu fais du RAID 5 avec deux disques ?

On parlait de swap hors raid, en fournissant directement les partitions 
physiques au noyau qui
se débrouille très bien avec (en distribuant les écritures, ce qui revient à un 
raid0).


Plus précisément, on parlait de la comparaison entre trois swaps en 
parallèle sur trois disques et un swap en RAID 5 sur les mêmes trois 
disques. Je te cite pour mémoire :



C'est aussi ce que je fais sur toutes mes machines à 3 disques
- sd(a|b|c)1 de ~10G pour / en raid1 (ça bootera toujours tant qu'il reste un 
disque sur les 3)
- sd(a|b|c)2 pour du swap (volume suivant le besoin)
- sd(a|b|c)3 pour le raid5 mdadm


Si je ne m'abuse, le rapport de performance entre un RAID 5 sur N 
disques et un disque seul est de N-1, soit 2 pour N=3. Donc le rapport 
de performance entre 3 swaps en parallèle (équivalent RAID 0) et un swap 
en RAID 5 est de 3/2 = 1,5, pas 3.

Re: Alternativa ao Usermin para usuario alterar senha via web

[Henrique Fagundes]

Prezados,

Obrigado a todos que responderam.
Vou dizer como resolvi a questão.

Decidi usar o próprio Usermin, só que, habilite o mod_proxy no meu 
apache e fiz o usuário final (cliente) chegar ao servidor pela porta 80.


http://usermin.meucliente.com.br

Eu estava evitando usar o Usermin porque não queria que usuário tivesse 
que acessar http://usermin.meucliente.com.br:2 (esteticamente feio). 
E também não poderia trocar a porta do Usermin para a 80, pois já tenho 
o Apache rodando nela.


Daí eu me lembrei do mod_proxy do apache, e, problema resolvido.

Obrigado a todos.

Atenciosamente,

Henrique Fagundes
henri...@linuxadmin.com.br
Skype: magnata-br-rj
Linux User: 475399

https://www.aprendendolinux.com
https://www.facebook.com/AprendendoLinux
https://youtube.com/AprendendoLinux
https://twitter.com/AprendendoLinux
https://telegram.me/AprendendoLinux
__
Participe do Grupo Aprendendo Linux
https://groups.google.com/forum/#!forum/portal-aprendendo-linux

Ou envie um e-mail para:
portal-aprendendo-linux+subscr...@googlegroups.com

 Mensagem original 
Assunto: Re: Alternativa ao Usermin para usuario alterar senha via web
De: Paulino Kenji Sato 
Para: Henrique Fagundes 
CC: Debian Brasil 
Data: 03/12/2017 16:48


Boa tarde.
Então, esses usuários não possuem acesso interativo com o servidor? Ou 
seja, não possuem qualquer tipo de acesso a shell, terminal ou X11.


Se possuírem uma shell (mesmo que não a use), pode emular uma sessão 
telnet ou ssh via php e enviar os comandos para a troca de senha.
Evite soluções que precisem forçar permissões de root, como o uso de 
sudo ou similar (além dos que já são fornecidos pelo sistema).


Caso os usuários realmente não precisem de uma shell, como em um 
servidor de email, pode-se migrar a base de usuários para um mais fácil 
de lidar externamente, como LDAP, SQL, etc.
Usuários do samba podem trocar a senha via o windows ou outra ferramenta 
SMB/CIFS. A senha do samba pode ser sincronizado com o do passwd/shadow.




2017-11-30 18:21 GMT-02:00 Henrique Fagundes >:


Prezados Colegas,

Boa tarde e saudações "pinguianas" para todos.

Gostaria de saber se alguém pode me indicar uma alternativa ao
Usermin. Preciso implementar uma forma do usuário poder alterar a
senha dele a partir de uma página web.

Pode ser em php.

Só é preciso que ele possa entrar com a senha antiga dele, colocar a
nova e confirmar.

Os usuários são nativos do Linux, então basicamente o que o sistema
tem que fazer é um "passwd usuario".

Alguém conhece alguma solução em PHP que faça isso?

Ficarei muito grato se alguém puder ajudar.

Atenciosamente,

Henrique Fagundes
henri...@linuxadmin.com.br 
Skype: magnata-br-rj
Linux User: 475399

https://www.aprendendolinux.com 
https://www.facebook.com/AprendendoLinux

https://youtube.com/AprendendoLinux

https://twitter.com/AprendendoLinux

https://telegram.me/AprendendoLinux

__
Participe do Grupo Aprendendo Linux
https://groups.google.com/forum/#!forum/portal-aprendendo-linux


Ou envie um e-mail para:
portal-aprendendo-linux+subscr...@googlegroups.com





--
Paulino Kenji Sato

Re: Boot et RAID5

[Andre Majorel]

On 2017-12-05 00:23 +0100, Pascal Hambourg wrote:
> Le 04/12/2017 à 15:13, Daniel Caillibaud a écrit :
>
> >Si ça arrive quand même, c'est qu'il
> >y a un souci et il vaut mieux qu'il soit le plus rapide possible pour
> >éviter que ça ne
> >dégénère (car dans ce cas, y'a souvent de l'effet domino, le système sature
> >car y'a trop de
> >trucs à faire, le swap le ralenti bcp donc il traite moins de chose et
> >sature encore plus,
> >jusqu'à ce qu'un oomkill passe par là).

Mettre des retours chariot, c'est bien, mais encore faut il que
la longueur de ligne qui en résulte soit assez petite pour être
bénéfique. Faire des lignes de 100 caractères, c'est pire que
tout. Pour ceux qui ont le malheur de lire ça sur un terminal de
80, cette méthode a les inconvénients du texte au kilomètres,
c'est à dire des lignes trop longues (plus de 66 caractères) et
la mocheté du wrapping automatique, /plus/ une marge de droite
en dents de scie (une ligne de 80, une ligne de 20, une ligne de
80...).

> On peut soutenir un point de vue opposé : plus le swap est
> lent, plus il laisse de temps pour réagir avant que lui aussi
> soit plein. D'autre part, swapper ne signifie pas forcément
> "thrasher". Par exemple une fuite mémoire va progressivement
> remplir le swap mais n'en sortira jamais.

C'est vrai... Jusqu'à ce qu'on veuille terminer le processus en
question. À moins d'être brutal (kill -9), les routines avant
exit() font remonter toute cette cochonnerie en mémoire. La
plupart du temps uniquement pour pouvoir faire free() dessus ou
son équivalent, ce qui ne sert à rien puisqu'on va faire sbrk()
juste après. Mais soyons positifs, ça donne le temps de faire
une pause. 

-- 
André Majorel 
bugs.debian.org, an essential online resource for spammers.

Re: EDA software.

[Fred]

On 12/06/2017 09:57 AM, pe...@easthope.ca wrote:

Hi,

At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of
packages for electronics design automation.  According to various
documents, Electric, Fritzing and gEDA, at least, can help to create
schematics.  I use librecad but have never used schematic construction
software.  Which of the EDA packages will be a good starting point?
Is any integrated with Librecad?

Thanks,... Peter E.
I recommend xcircuit for schematic capture.  The author Tim Edwards at 
opencircuitdesign.com is very helpful.


Best regards,
Fred Boatwright

Re: Un buen antivirus...

[u-01]

30. Nov 2017 10:57 by luiseded...@nauta.cu:


> On Wed, 29 Nov 2017 13:02:52 -0500, Cristian Mitchell <> 
> mitchell6...@gmail.com> > wrote:
>
>> El 29 de noviembre de 2017, 14:42, luisededios<>> luiseded...@nauta.cu>> >
>> escribió:
>>
>>> On Wed, 29 Nov 2017 10:47:24 -0500, JAP <>>> 
>>> javier.debian.bb...@gmail.com>>> >
>>> wrote:
>>>
>>> El 29/11/17 a las 11:16, luisededios escribió:
> Hola amigos listeros,
>  Quiero instalar un antivirus en mi laptop -core dos duo, 8GB de RAM y
> debian 9- y quisiera escuchar alguna sugerencia.
>  No tengo repos locales pero tengo internet por lo que agradezco
> cualquier consejo que puedan impartirme  :)
>
>

 ClamAV

 https://www.clamav.net

 Los antivirus en GNU/Linux son para proteger a las máquinas Windows que
 tenga conectadas, como, por ejemplo, aquellas a las que funja como servidor
 de correos o de recursos compartidos.

>>>
>>> Pero sabemos que linux tambien puede ser infectado con malware, no es asi?
>>>
>>> Está en el repositorio
 # apt search clamav
 Ordenando... Hecho
 Buscar en todo el texto... Hecho

 clamav/testing,now 0.99.3~beta1+dfsg-4 amd64 [instalado, automático]
anti-virus utility for Unix - command-line interface

>>>
>>> Ya lo instale.
>>>
>>> Y bueno, como se actualiza, cada que tiempo deberia hacerlo alguien que se
>>> conecta a internet todos los dias?  :)
>>>
>>> --
>>> Saludos,
>>> Luis
>>>
>>>
>> bien dijiste  malware, pero pediste antivirus
>> no son lo mismo y el clamav es para virus de windows, como bien te aclararon
>
> Bueno, dije que tenia debian 9 y que queria escuchar sugerencias para el tema 
> de los codigos maliciosos en linux, no debe ser tan dificil entender lo que 
> pregunto no?  :)
>>
>>
>> chkrootki
>>
>> es muy importante hacer bien las preguntas
>>
>>
>
>
>
> -- 
> Saludos,
> Luis




Hola, no soy experto, te doy mi sugerencia y la respuesta a lo que buscás.


Con lo que respecta a antivirus, suites de seguridad, etc.. tiene muchísimo 
contenido comercial/marketing y está muy inflado . 





Un sistema se corrompe descubriendo una falla, un exploit,  una vulnerabilidad 
no corregida aún, también por error o inocencia humana. Con un malware o sin 
necesidad de éste. 


En algunos/varios casos un AV (que esté actualizado obvio) puede detener algun 
malware que explote una falla no corregida aun. Pero no siempre.



En resumen, el valor de un antivirus/suites de seguridad radica en que sus 
firmas estén al día.
Por lo tanto sería como una actualización parcial de una actualización 
pendiente del sistema. 


En lo personal no le veo sentido, y más aún teniendo en cuenta que en velocidad 
nadie le gana a la comunidad GNU/Linux descubriendo y corrigiendo fallos.




Si realmente te interesa la seguridad en Linux suscribite a las Security 
Advisories de Debian y vas a tener un panorama real.

Si te ponés  a estudiar nmap, iptables, sudo, una live-iso de "auditorías 
éticas" Ahí sí que te vas a sentir seguro (o lujurioso, depende para que lado 
agarres)





Bueno al respuesta: actualmente hay unos 4 o 5 exclusivos para Linux. No te los 
nombro porque no se si se puede por acá. Pero duckduckealos y los encontrás ya 
que son los más populares y están todos a la par en cuánto a detección (o sea 
poco)


















 

Re: EDA software.

[Elimar Riesebieter]

* Joe  [2017-12-06 18:31 +]:

[...]
> I'm not sure what kind of connection with LibreCAD there could be: DXF
> is a much more complex file structure, and I think the most that could
> be done would be to transfer PCB outlines and mounting points. There is
> some provision for component height in PCB, but no easy way to
> manipulate values, and I don't believe LibreCAD can do anything in the
> way of 3D anyway.

kicad seems to be able to im/export dxf format. There are also
existing powerful 3-D libraries [0]. With those implemented you'll
be able to design 3-D pcb's and export them as STEP-214 to pull them
in to a 3-D capable CAD system which is useful to design housings,
complete devices etc. ...

Elimar
[0] http://smisioto.no-ip.org/elettronica/kicad/kicad-en.htm
-- 
  On the keyboard of life you have always
  to keep a finger at the escape key;-)

Re: EDA software.

[John Conover]

pe...@easthope.ca writes:
> 
> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of 
> packages for electronics design automation.  According to various 
> documents, Electric, Fritzing and gEDA, at least, can help to create 
> schematics.  I use librecad but have never used schematic construction 
> software.  Which of the EDA packages will be a good starting point?  
> Is any integrated with Librecad?
>

Hi Peter. All the files in gEDA are text files, and its very
extensible.  There is an active community for gEDA; the specialty is
analog design, (although many use it for digital.) Kicad is an
alternative with a larger user base; the specialty is digital
design. Both have mailing list support and are good choices.

Presumably, you want to do schematic capture, (for simulation, PCB
production, etc.) If you are going to do PCB prototyping in house,
gEDA has a slight advantage. If you are outsourcing PCB production,
Kicad has a slight advantage.

gEDA will probably require you to make some component foot prints,
(although there is a library of the most used components,) which is
easy enough. Kicad has a large library of foot prints.

Both have hooks into the common EDA/CAD/CAM programs, (spice, etc.,)
but setting stuff up is a bit of a pain in both cases.

gEDA is user supported, Kicad is supported by CERN.

Suggestion: try both. gEDA is available via apt-get from the Debian
repository. Decide on only one, (either is a good choice.)
Transporting a design back-and-forth between the two systems is
tricky, at best.

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/

Re: EDA software.

[Michael Milliman]

I have used several of the choices mentioned. I have settled on gEDA suite
for a couple of times reasons. First, using the proper tool chain, it
integrates with the ngspice and gnucap simulators. It also allows complete
project creation from schematic thru simulation to PC board layout.

It is true that the learning curve is rather steep, but it is well worth
your while to take the time to learn how to use these tools.

73s de WB5VQX

On Dec 6, 2017 12:31, "Joe"  wrote:

On Wed, 06 Dec 2017 08:57:09 -0800
pe...@easthope.ca wrote:

> Hi,
>
> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of
> packages for electronics design automation.  According to various
> documents, Electric, Fritzing and gEDA, at least, can help to create
> schematics.  I use librecad but have never used schematic
> construction software.  Which of the EDA packages will be a good
> starting point? Is any integrated with Librecad?
>

I suspect they all have a bit of a learning curve. The gEDA suite is
probably the most difficult, but I haven't tried any alternative, there
were none when I began and I don't really feel like changing horses
now. I suspect it is also the most powerful.

What people like about other systems is the 'integration'. The gEDA
suite is clearly two disparate major tools, with completely different
file structures, but as both are text based, it's not hard to plumb one
into the other. There are a number of command-line utilities, and
scripts and spreadsheets to generate families of parts.

I find I need to make most of the footprints I use, and a lesser number
of schematic symbols: there are libraries, and many user contributions
around the Net, but there are so many hundreds of thousands of parts
that a lot have to be made from scratch, which isn't difficult.

I'm not sure what kind of connection with LibreCAD there could be: DXF
is a much more complex file structure, and I think the most that could
be done would be to transfer PCB outlines and mounting points. There is
some provision for component height in PCB, but no easy way to
manipulate values, and I don't believe LibreCAD can do anything in the
way of 3D anyway.

--
Joe

Re: EDA software.

[Elimar Riesebieter]

* pe...@easthope.ca  [2017-12-06 08:57 -0800]:

> Hi,
> 
> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of 
> packages for electronics design automation.  According to various 
> documents, Electric, Fritzing and gEDA, at least, can help to create 
> schematics.  I use librecad but have never used schematic construction 
> software.  Which of the EDA packages will be a good starting point?  
> Is any integrated with Librecad?

I'd give kicad a shot:

apt-cache show kicad

Have a look at http://kicad-pcb.org/ too.

Elimar
-- 
  You cannot propel yourself forward by
  patting yourself on the back.

Re: EDA software.

[Joe]

On Wed, 06 Dec 2017 08:57:09 -0800
pe...@easthope.ca wrote:

> Hi,
> 
> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of 
> packages for electronics design automation.  According to various 
> documents, Electric, Fritzing and gEDA, at least, can help to create 
> schematics.  I use librecad but have never used schematic
> construction software.  Which of the EDA packages will be a good
> starting point? Is any integrated with Librecad?
> 

I suspect they all have a bit of a learning curve. The gEDA suite is
probably the most difficult, but I haven't tried any alternative, there
were none when I began and I don't really feel like changing horses
now. I suspect it is also the most powerful. 

What people like about other systems is the 'integration'. The gEDA
suite is clearly two disparate major tools, with completely different
file structures, but as both are text based, it's not hard to plumb one
into the other. There are a number of command-line utilities, and
scripts and spreadsheets to generate families of parts.

I find I need to make most of the footprints I use, and a lesser number
of schematic symbols: there are libraries, and many user contributions
around the Net, but there are so many hundreds of thousands of parts
that a lot have to be made from scratch, which isn't difficult.

I'm not sure what kind of connection with LibreCAD there could be: DXF
is a much more complex file structure, and I think the most that could
be done would be to transfer PCB outlines and mounting points. There is
some provision for component height in PCB, but no easy way to
manipulate values, and I don't believe LibreCAD can do anything in the
way of 3D anyway.

-- 
Joe

Re: EDA software.

[deloptes]

pe...@easthope.ca wrote:

> At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of
> packages for electronics design automation.  According to various
> documents, Electric, Fritzing and gEDA, at least, can help to create
> schematics.  I use librecad but have never used schematic construction
> software.  Which of the EDA packages will be a good starting point?
> Is any integrated with Librecad?

Hi,
I am not an expert, just for hobby used few times the packages. And I don't
know if it is integrated in librecad. chances are good because they use
well known formats, but no idea.
on the other hand it depends on what you want to do. For example I used geda
(gschem) to create a model and ngspice as simulator to test it and then
export the schematics and design the layout in pcb (gsch2pcb). 

For few small projects it worked very good.

I hope it helps

EDA software.

[peter]

Hi,

At https://wiki.debian.org/DebianTinker/Desktop#EDA is a list of 
packages for electronics design automation.  According to various 
documents, Electric, Fritzing and gEDA, at least, can help to create 
schematics.  I use librecad but have never used schematic construction 
software.  Which of the EDA packages will be a good starting point?  
Is any integrated with Librecad?

Thanks,... Peter E.
-- 

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202  Pender Is.: +1 250 629 3757
http://easthope.ca/Peter.html  Bcc: peter at easthope. ca

Re: [OT] Relavant mailing list or USENET group

[Richard Owlett]

On 12/06/2017 05:36 AM, Richard Hector wrote:

On 06/12/17 23:46, Dan Purgert wrote:

Eric S Fraga wrote:

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable



On Tuesday,  5 Dec 2017 at 14:53, Richard Owlett wrote:



[...]



I've seen the term "RSS", but never had any contact with it. Not sure
if SeaMonkey 2.48 can use it.



No idea.  Never used SeaMonkey...


2 seconds of googling indicate you'd likely need a plugin.  But if "use
a plugin" is good enough, then "yes Seamonkey supports RSS feeds"


https://www.seamonkey-project.org/doc/features

"*Feed detection* notifies you when web pages offer RSS or Atom feeds,
and feed preview lets you view their contents and choose a reader with
which to subscribe to those—including an internal reader in the Mail &
Newsgroups component of SeaMonkey."

"*Blogs & News Feeds* is a reader for RSS and Atom feeds right in your
messaging center that eases your reading of information from all across
the web."

Richard



ROFL
I had first used F1  entering RSS in "Search box".
All it had was links to a couple of definitions ;{
HOWEVER, using "feed" as search term yielded a copious plethora of info.
Looks like I have a reading assignment.
*THANK YOU*

Re: Proxy server navegar

[Matias Mucciolo]

On Tuesday, December 5, 2017 4:15:07 PM -03 Edwin Quijada wrote:
> Hola.!
> Necesito crear un proxy server para poder navegar con IP de USA pero no se
> como hacerlo. Lo que deseo es tener una direccion en la cual pueda navegar
> desde este servidor desde mis PC. Tengo varias paginas de USA que no puedo
> acceder desde mi pais por lo que necesito poder navegar con IP extranjera
> algo como esta pagina.
> 
> https://www.megaproxy.com/freesurf/
> 
> 
> 
> Alguna idea de como hacerlo, tengo un server en USA para hacer esto.
> 
> 
> Gracias
> 
> Megaproxy® - Free anonymous proxy
> surfing www.megaproxy.com
> Megaproxy offers secure free anonymous web proxy surfing. Surf the Web
> privately with our free proxy service

hola 
proba con tor ..
es medio lento perooo..maso o menos anonimo..
y no solo tenes ips de usa sino de varias partes del mundo.

saludos
Matias

Re: [OT] Relavant mailing list or USENET group

[Richard Hector]

On 06/12/17 23:46, Dan Purgert wrote:
> Eric S Fraga wrote:
>> --=-=-=
>> Content-Type: text/plain
>> Content-Transfer-Encoding: quoted-printable
> 
>> On Tuesday,  5 Dec 2017 at 14:53, Richard Owlett wrote:
> 
>> [...]
> 
>>> I've seen the term "RSS", but never had any contact with it. Not sure
>>> if SeaMonkey 2.48 can use it.
> 
>> No idea.  Never used SeaMonkey...
> 
> 2 seconds of googling indicate you'd likely need a plugin.  But if "use
> a plugin" is good enough, then "yes Seamonkey supports RSS feeds"

https://www.seamonkey-project.org/doc/features

"*Feed detection* notifies you when web pages offer RSS or Atom feeds,
and feed preview lets you view their contents and choose a reader with
which to subscribe to those—including an internal reader in the Mail &
Newsgroups component of SeaMonkey."

"*Blogs & News Feeds* is a reader for RSS and Atom feeds right in your
messaging center that eases your reading of information from all across
the web."

Richard



signature.asc
Description: OpenPGP digital signature

Re: [OT] Relavant mailing list or USENET group

[Richard Owlett]

On 12/06/2017 04:46 AM, Dan Purgert wrote:


Eric S Fraga wrote:

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tuesday,  5 Dec 2017 at 14:53, Richard Owlett wrote:

[...]


I've seen the term "RSS", but never had any contact with it. Not sure
if SeaMonkey 2.48 can use it.


No idea.  Never used SeaMonkey...


2 seconds of googling indicate you'd likely need a plugin.  But if "use
a plugin" is good enough, then "yes Seamonkey supports RSS feeds"




In my search I intended to rule out plugins etc. [Intentionally have 
avoided plugins since Netscape days - a personal preference]. I came 
across some posts suggestive that RSS was available at one time.

Re: Proxy server navegar

[Gonzalo Rivero]

El mar, 05-12-2017 a las 16:15 +, Edwin Quijada escribió:
> Hola.!
> Necesito crear un proxy server para poder navegar con IP de USA pero
> no se como hacerlo. Lo que deseo es tener una direccion en la cual
> pueda navegar desde este servidor desde mis PC. Tengo varias paginas
> de USA que no puedo acceder desde mi pais por lo que necesito poder
> navegar con IP extranjera algo como esta pagina.
> https://www.megaproxy.com/freesurf/
> 
> 
> Alguna idea de como hacerlo, tengo un server en USA para hacer esto.
> 
> Gracias
>   Megaproxy® - Free anonymous proxy surfing www.megaproxy.com
> Megaproxy offers secure free anonymous web proxy surfing. Surf the
> Web privately with our free proxy service
> 

apt-get install squid

(y, por si no te gusta, seguramente hay otros servidores de proxy por
ahí, apt-cache search proxy)

Re: [OT] Relavant mailing list or USENET group

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric S Fraga wrote:
> --=-=-=
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Tuesday,  5 Dec 2017 at 14:53, Richard Owlett wrote:
>
> [...]
>
>> I've seen the term "RSS", but never had any contact with it. Not sure
>> if SeaMonkey 2.48 can use it.
>
> No idea.  Never used SeaMonkey...

2 seconds of googling indicate you'd likely need a plugin.  But if "use
a plugin" is good enough, then "yes Seamonkey supports RSS feeds"

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaJ8qOAAoJEI4R3fMSeaKBHwcH/jzg4KOLM+DbRBLDOMbkVKcx
Vmb1t+qsmA8zNPOgNow/Rxpoz+B71IqU9gqhmckHzSV1laUie0g7jxoh2ALUrvyU
k2TrDeFmMSkCsiuNnbgomVi0t+yknkkac5IPI6LiVajbbdm0zxrI7YeQV4CGQwXU
V3P88xuI2STtOIX/U0NOcQ2rOj18XL8uPWwAR3Ssyj3A7UWDYP2Lys+OmzyK45EK
dHI9iLefDQcMUjnp/ExSpXL3QFrARVzh3IGE+QEXVKRsldH4anAD6f4MHsOdl/Qd
qqbHpSQbalbrIQDBs9YVfhx425A456ZNn/xDxbOiLMVgoF6fFiX/1IQDbPR/n8s=
=71o6
-END PGP SIGNATURE-

-- 
|_|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: Boot et RAID5

[Daniel Caillibaud]

Le 05/12/17 à 23:35, Pascal Hambourg  a écrit :

PH> Le 05/12/2017 à 08:53, Eric Degenetais a écrit :
PH> > Le 5 déc. 2017 12:23 AM, "Pascal Hambourg"  a
PH> > écrit :
PH> > 
PH> > Pardon ? Un risque de plantage si un support de stockage est "trop" lent
PH> > (1,5 fois plus, la belle affaire), tu sors ça d'où ?
PH> > 
PH> > Accumulation dynamique d'une charge de travail qui serait passée si le
PH> > swap, et donc le système, avaient répondu plus vite, et donc réussi à
PH> > terminer les tâches en cours avant le déclenchement des suivantes. Une
PH> > telle spirale peut mener à la saturation de la mémoire virtuelle jusqu'à
PH> > saturation complète, avec pour résultat un plantage (oom kill d'un service
PH> > important, ou plantage d'un processus auquel de la mémoire est refusée)  
PH> 
PH> Si cela arrive, je dis : système mal conçu avec des limites de charge 
PH> mal réglées et des marges insuffisantes.

Oui, c'est des choses qui arrivent dans la vraie vie… Un service calibré pour 
avoir N childs
max prenant X RAM max chacun, et un jour ils consomment plus… Et souvent en 
conséquence un
autre service se met à consommer davantage également => ça dépasse le max de 
RAM physique et se
met à swapper.

PH> Et si je pousse ton raisonnement, la redondance du RAID ne sert à rien 
PH> car en cas de panne d'un disque le RAID dégradé aura des performances 
PH> moins bonnes et le système risque de s'écrouler sous la charge...

Je préconisais un swap plus rapide (mais moins fiable) pour faire face à un 
contexte
exceptionnel, justement quand ça dépasse les limites de charge prévues.

Par ex un applicatif avec une requête bdd mal écrite qui dans un certain 
contexte bouffe bcp de
ressources => les autres requêtes attendent ou sont plus lentes, applicatif + 
bdd + serveur web
+ frontal se mettent tous à avoir plus de threads / process => conso de RAM qui 
augmente.

Avec un swap rapide, la probabilité pour que tout fonctionne quand même est 
plus élevée, c'est
tout ce que je disais.

Dans un usage du swap de cet ordre, le fait qu'il soit rapide mais pas sécure 
augmente la
fiabilité plutôt que la réduire.

-- 
Daniel

L'inconnaissable est connaissable puisque
je peux connaître qu'il est inconnaissable.
Aristote, Poétique.

Re: Boot et RAID5

[Daniel Caillibaud]

Le 05/12/17 à 20:36, Pascal Hambourg  a écrit :
PH> Le 05/12/2017 à 11:09, Daniel Caillibaud a écrit :
PH> > Le 05/12/17 à 00:23, Pascal Hambourg  a écrit :  
PH> > PH> (1,5 fois plus, la belle affaire),  
PH> > 
PH> > Je penses que c'est bien ×3 si tu donnes au noyau 3 partitions de swap 
sur 3 disques
PH> > différents, en tout cas avec 2 disques j'avais effectivement mesuré du ×2 
en lecture et
PH> > écriture.  
PH> 
PH> Peux-tu expliquer comment tu fais du RAID 5 avec deux disques ?

On parlait de swap hors raid, en fournissant directement les partitions 
physiques au noyau qui
se débrouille très bien avec (en distribuant les écritures, ce qui revient à un 
raid0).

Avec 2 disques tu mets dans fstab
/dev/sdaN none swap …
/dev/sdbN none swap …

et ça multiplie les perfs par 2, avec un 3e tu ajoutes 
/dev/sdcN none swap …
et ça fait ×3, mais effectivement si un disque lâche le swap est tout cassé et 
le système va
pas aimer.

Pour s'en prémunir, ce que tu préconises, un swap sur du raid avec une seule 
ligne
/dev/mdX none swap

À chacun de voir ce qui est le plus efficace dans son contexte…

-- 
Daniel

Il est juste que celle qui a tue son mari meure.
Il est beau qu'un fils venge son père.
Donc il est juste et beau qu'un fils tue sa mère.
Aristote, Rhétorique, 2, 24

Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable) after Upgrade

[basti]

Hello,

I have upgrade my debian samba domain controller yesterday.
After that I get on both (dc1 and dc2) this error:

Could not get lock /var/lib/apt/lists/lock - open (11: Resource
temporarily unavailable)

I have try to remove the look and list files, reconfigure all installed
packages but the error is still present. I have also try to reboot.

Any ideas how can I fix this?

Best Regards,
basti

Re: Nvidia driver installing newer releases from SVN

[Floris]

Op Tue, 05 Dec 2017 21:03:46 +0100 schreef Benny Simonsen  
:



Hi,

System: Fresh Debian 9
I have a Nvidia GT 1030, that needs 384 (or newer), and I have followed  
the guide listed here:

https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_releases_from_SVN
Last step: svn-buildpackage --svn-ignore -us -uc -rfakeroot

But whats next, have tried cd to buid-area folder, containg the deb  
files, and "dpkg -i *.deb", but leaves unconfigured >packages and other  
issues.


Not all packages are needed and can't be installed at the same time (glvnd  
and non-glvnd). Start with the nvidia-driver meta package and resolve the  
dependencies. Or make a local repo and let apt resolve the dependencies.