Re: Question to new network device names

[David Wright]

On Fri 25 Aug 2017 at 00:54:11 (-0400), Gene Heskett wrote:
> On Thursday 24 August 2017 22:15:53 David Wright wrote:
> 
> > On Thu 24 Aug 2017 at 20:58:18 (-0400), Gene Heskett wrote:
> > > On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:
> > > > On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > > > > The history of computing is littered with statements like
> > > > > "virtually every computer has exactly one or two NICs".
> > > >
> > > > It used to be zero.
> > > >
> > > > We are currently in the phase of history where this statement is
> > > > true. NICs are both ubiquitous and cheap, yet devices tend to
> > > > come with one (only an ethernet port or only a wifi radio) or
> > > > two (one of each of those, or a wifi radio and a cell radio).
> > > >
> > > > Devices can add more, but they are always special cases: my
> > > > Debian-running firewall has 5 ethernet ports. I occasionally
> > > > add a USB ethernet frob in order to isolate a device that I want
> > > > to talk to directly. Special cases deserve special treatment.
> > > >
> > > > I expect the statement to remain true for the next ten years.
> > > >
> > > > Do you expect differently? If so, why?
> > > >
> > > > > This list is full of postings about the complex DNS system. But
> > > > > how long did /etc/hosts last? Some complexity is unavoidable,
> > > > > but if you try to avoid it, you pay for it later. Look at
> > > > > timezones. Ever allowing computers' internal clocks to run on
> > > > > local time was, with hindsight, a big mistake. Leap seconds
> > > > > might also be seen the same way (still under debate).
> > > >
> > > > /etc/hosts still acts the way it always did -- put in an entry,
> > > > it overrides DNS.
> > >
> > > That depends entirely on who wrote your /etc/resolv.conf and whether
> > > or not your did a sudo chattr +i /etc/resolv.conf, immediately after
> > > verifying that it works. (and of course that implies it is a real
> > > file, not a softlink to something else.  With N-M in the mix and
> > > active that is the only way to keep it from tearing down your
> > > network configuration and leaving you empty files, and no network,
> > > if it cannot find a dhcpd server)
> >
> > (We've heard about your problems concerning /etc/resolv.conf
> > several times now.)
> >
> > I think the file that affects the priority of /etc/hosts is
> > /etc/nsswitch.conf which typically contains a line like:
> >
> > hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
> >
> But what has that to do with having the proper entry's 
> in /etc/resolv.conf?  Whose active lines are:
> 
> nameserver 192.168.71.1
> search host,dns

I can't parse ↑ this line. Are you sure your resolver can?
Why does it contain a comma? Are "host" and "dns" domain names?

> domain coyote.den
> 
> I am willing to learn IF there is a simpler, even faster and more secure 
> way to do it than what I preach.  If those 3 criteria can be satisfied, 
> show me how.
> 
> That search line "hosts,dns" draws a fine line between my local network, 
> which is all in the /etc/hosts file, and the rest of this planet for 
> which I need a dns server. dd-wrt in my router relays the resolution 
> requests on to my ISP's assigned dns servers, and relays the results 
> back to whatever asked for it on my home network regardless of which 
> machine or program on that machine originated the request.
> 
> AFAIK, no other processing seems to be involved.  According to htop (root 
> session) no trace of named or any other dns helper can be found running 
> on any of the machines(5) running here ATM.  Pure, boiled it down to the 
> simplest way I know how, and it Just Works(TM). FWIW, denyhosts and 
> portsentry still work just fine.
> 
> Whats not to like?

Cheers,
David.

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 23:00:19 (-0400), The Wanderer wrote:
> On 2017-08-24 at 12:40, David Wright wrote:
> 
> > On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> 
> >> On 2017-08-24 at 11:43, David Wright wrote:
> 
> >>> There are plenty of ways that you, or Debian, can set a default.
> >>> But it surprises me that so many people grumble about this
> >>> change. The history of computing is littered with statements like
> >>> "virtually every computer has exactly one or two NICs".
> >> 
> >> The thing is, currently that statement[1] *is* correct, so
> >> *currently* the default should be suited for that configuration.
> >> 
> >> If things ever do reach a point where that is no longer the common
> >> case, it would then become appropriate to propose changing the
> >> default to one suited for that more-complex configuration.
> >> 
> >> But we are not yet there, or indeed anywhere close to there, so
> >> that should not yet be the default.
> > 
> > By that argument, you wait until lots of people have problems before 
> > you change the default to accomodate them, instead of thinking
> > ahead.
> 
> Well, yes - or at least until lots of people are *about to* have
> problems pretty soon, unless the default is changed first. That is at
> least preferable to *causing* lots of people to have problems (or at
> least experience additional inconvenience) by changing the default too
> far in advance.

I see. So you never consider the vanguard's problems or expectations?
If it's a question of timing, then waiting would usually suit me; as
I said, I'm usually at the trailing rather than the cutting edge.

> > If you want a simpler default, can you not follow the instructions 
> > and give yourself one.
> 
> Er... what?
> 
> A default is "what you get if you don't take steps to get something else".
> 
> If you have to take steps to achieve a given configuration, by
> definition that configuration is not the default.
> 
> Thus, since the "old" naming scheme here no longer comes as the default
> (for new installs, et cetera), I cannot make it the default.
> 
> I can certainly make local changes to get a non-default configuration,
> but that does not make that configuration the default.

Fair enough. Pick a word you prefer and override my choice of default.
Perhaps "prefer" or "override" will do. Meanwhile, I shall have words
with whoever chose the directory name /etc/default/. At the back of
my mind was adding net.ifnames=0 to GRUB_CMDLINE_LINUX in
/etc/default/grub.

> > For people upgrading, Debian ensured that there would not be an
> > unexpected change; the older methods prevail¹.
> 
> Missing footnote?

No, I put the matching ¹ at the words "udev's persistent-net rules"
in the footnote (which was more of an aside) as this is an older
method that prevails. I guess the visibility of the ¹ is something
I have no control over.

> >>> This list is full of postings about the complex DNS system. But
> >>> how long did /etc/hosts last?
> >> 
> >> It's still there and still in use, albeit not as a primary source,
> >> last I checked...
> > 
> > It's the *only* source here for such as 192.168.1.13wasp but I was
> > assuming you'd understand I was talking about non-local hosts on the
> > Internet.
> 
> Just offhand, I don't think I even remember a time when that file was
> used (outside of special one-off cases) for such hosts. I also don't
> remember encountering such a special one-off case in the past several
> years to a decade, at least, although I wouldn't be at all surprised to
> learn they still crop up.

That can't be right. You don't mean to say that people use
dotted quads to communicate with their local hosts. That's
a lot to commit to memory. I wouldn't say we have an abundance
of devices, but I am using over half the area I reserved for
static addresses, 16 out of 31. I might have been using more
but for the fact that IPv6 is available for direct links.

Cheers,
David.

Re: macbook keyboard layout

[Gene Heskett]

On Thursday 24 August 2017 23:58:51 ardawan wrote:

> Hi,
>
> unfortunately i am not able to get Tilde character work properly on
> Debian OS. I am using macbook pro retina 2015 and tried to key the
> keyboard layout in the settings to any available English option but
> still i get >or< instead of Tilde and seems nothing changed after
> choosing different layouts.
>
> I've tried to ask in different communities, but nobody could help me.
> Also, i've read the debian/macbook page but i couldn't figure it out.
>
> Please help me to fix this as i am choosing Debian as my primary OS.
>
> Thanks a lot.
> Ardawan
I believe that might be related to your locale  settings for language or 
charset.  Works fine ~ for EN, and utf8 here.

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: which display manager would you suggest for Stretch?

[kamaraju kusumanchi]

On Thu, Aug 24, 2017 at 5:35 AM, Michael Lange  wrote:
> Hi Raju,
>
> On Thu, 24 Aug 2017 02:37:41 -0400
> kamaraju kusumanchi  wrote:
>
> (...)
>> The popsort.py utility is written by me. It can be downloaded from
>> https://gitlab.com/d3k2mk7/rutils/blob/master/bin/popsort.py  and is
>> documented at
>> http://raju.shoutwiki.com/wiki/Sort_output_of_apt-cache_search_by_popularity 
>> .
>> I would appreciate if you have any feedback/comments/criticism on this
>> script (no matter how small you think it is).
>
> very nice indeed, thanks for sharing!

You are welcome.

> Only (very small) "criticism" (just because you were asking): I think the
> output would be more "intuitive" to read if the most popular package
> appears in the output first. I think adding a "sorted_lines.reverse()" in
> sort_lines() just before the "return" statement would do that. But maybe
> this is only my personal preference at all and other people like it
> better the way it is.

Thanks for the feedback. I added this under a new option,
--most-popular-first. So, if you do

% apt-cache search display manager --names-only | popsort.py
--most-popular-first
1595 gdm3 - GNOME Display Manager
1999 lightdm - simple display manager
4337 sddm - modern display manager for X11
9363 xdm - X display manager
10218 slim - desktop-independent graphical login manager for X11
18484 lxdm - LXDE display manager
21307 wdm - WINGs Display Manager - an xdm replacement with a WindowMaker look
22060 nodm - automatic display manager

it will list the most popular package first. However, I left the
default as is. I prefer having the most popular package at the bottom
as it minimizes "the eyeball movement". Consider, for example, a
command that produces multiple pages of output such as

% apt-cache search "^vim-" --names-only | popsort.py

To look at a few of the famous packages in this, one has to either
scroll up or pipe the output to head. With the current sorting method,
you can keep eyes closer to the command line and still get all the
important information.

raju
-- 
Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog

Re: Debian v9 it's a stretch

[Ben Finney]

Borden Rhodes  writes:

> To answer an earlier question about why I don't report all the bugs I
> find in software: I choose my battles.

I don't recall anyone asking why you don't report all bugs you find in
software, that would be a fatuous question.

You were asked specifically about the bugs in Debian Stretch that you
encountered and you said you were surprised Stretch was released with
those bugs not fixed.

The question is not why you don't report all bugs. The question is, if
there are bugs you ahven't reported in time for them to be investigated
prior to release, how can you claim surprise when they aren't fixed in
time for release?

-- 
 \  “Courage is not the absence of fear, but the decision that |
  `\ something else is more important than fear.” —Ambrose Redmoon |
_o__)  |
Ben Finney

Re: Debian v9 it's a stretch

[Borden Rhodes]

>> > Do you find checking for possible rootkits is useless, or you are just
>> > not happy how rkhunter performs that function?
>>
>> A well-documented case of rkhunter discovering a rootkit in the last
>> ten years (the 1000s of false positives do not count) would go a long
>> way to establishing its credence,
>>
>
> So, those in security/forensics who recommend use of rkhunter have just
> been silly? Interesting. But think that I'll use it anyway, just to be
> on the safe side. It does not hurt.

Ahh, that's what I love about FOSS software. Most bugs are 'closed' by
saying 'That package is garbage, don't use it'. It's like when you go
to a store and the salesperson says 'Buy this brand. That brand is
garbage.' I always wonder 'Well why are you selling it, then, if
nobody should buy it?!'

I encourage everyone to check out "How to Irritate People salesmen" on
your favourite community video streaming site. That's how I've found
FOSS support: "Best software in the world. No problems at all. But if
you find a problem, file a bug and we'll fix it." "Well I have filed a
bug, and you haven't fixed it." "Nope, no problems with this software
at all..."

To answer an earlier question about why I don't report all the bugs I
find in software: I choose my battles. Some bugs are easier to work
around than others, so I stick to reporting the ones that I can write
solid reports on that have a chance of being fixed.

Re: Question to new network device names

[Gene Heskett]

On Thursday 24 August 2017 22:15:53 David Wright wrote:

> On Thu 24 Aug 2017 at 20:58:18 (-0400), Gene Heskett wrote:
> > On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:
> > > On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > > > The history of computing is littered with statements like
> > > > "virtually every computer has exactly one or two NICs".
> > >
> > > It used to be zero.
> > >
> > > We are currently in the phase of history where this statement is
> > > true. NICs are both ubiquitous and cheap, yet devices tend to
> > > come with one (only an ethernet port or only a wifi radio) or
> > > two (one of each of those, or a wifi radio and a cell radio).
> > >
> > > Devices can add more, but they are always special cases: my
> > > Debian-running firewall has 5 ethernet ports. I occasionally
> > > add a USB ethernet frob in order to isolate a device that I want
> > > to talk to directly. Special cases deserve special treatment.
> > >
> > > I expect the statement to remain true for the next ten years.
> > >
> > > Do you expect differently? If so, why?
> > >
> > > > This list is full of postings about the complex DNS system. But
> > > > how long did /etc/hosts last? Some complexity is unavoidable,
> > > > but if you try to avoid it, you pay for it later. Look at
> > > > timezones. Ever allowing computers' internal clocks to run on
> > > > local time was, with hindsight, a big mistake. Leap seconds
> > > > might also be seen the same way (still under debate).
> > >
> > > /etc/hosts still acts the way it always did -- put in an entry,
> > > it overrides DNS.
> >
> > That depends entirely on who wrote your /etc/resolv.conf and whether
> > or not your did a sudo chattr +i /etc/resolv.conf, immediately after
> > verifying that it works. (and of course that implies it is a real
> > file, not a softlink to something else.  With N-M in the mix and
> > active that is the only way to keep it from tearing down your
> > network configuration and leaving you empty files, and no network,
> > if it cannot find a dhcpd server)
>
> (We've heard about your problems concerning /etc/resolv.conf
> several times now.)
>
> I think the file that affects the priority of /etc/hosts is
> /etc/nsswitch.conf which typically contains a line like:
>
> hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
>
But what has that to do with having the proper entry's 
in /etc/resolv.conf?  Whose active lines are:

nameserver 192.168.71.1
search host,dns
domain coyote.den

I am willing to learn IF there is a simpler, even faster and more secure 
way to do it than what I preach.  If those 3 criteria can be satisfied, 
show me how.

That search line "hosts,dns" draws a fine line between my local network, 
which is all in the /etc/hosts file, and the rest of this planet for 
which I need a dns server. dd-wrt in my router relays the resolution 
requests on to my ISP's assigned dns servers, and relays the results 
back to whatever asked for it on my home network regardless of which 
machine or program on that machine originated the request.

AFAIK, no other processing seems to be involved.  According to htop (root 
session) no trace of named or any other dns helper can be found running 
on any of the machines(5) running here ATM.  Pure, boiled it down to the 
simplest way I know how, and it Just Works(TM). FWIW, denyhosts and 
portsentry still work just fine.

Whats not to like?

> But that misses the point I was making, which requires one to know
> a fragment of Internet history. /etc/hosts started life as a file
> containing the address of every host on the network (then ARPANET).
> Simple, sufficient at the time, but obviously not going to stay
> the course.
>
> Similarly, /dev/sdX just about works well enough for simple, static
> systems but not for more complex, dynamic ones; eth0 likewise is
> showing its age for scaling and flexibility, particularly as the
> newer scheme adds functionality without removing the legacy.
>
> Cheers,
> David.


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 

macbook keyboard layout

[ardawan]

Hi,

unfortunately i am not able to get Tilde character work properly on 
Debian OS. I am using macbook pro retina 2015 and tried to key the 
keyboard layout in the settings to any available English option but 
still i get >or< instead of Tilde and seems nothing changed after 
choosing different layouts.


I've tried to ask in different communities, but nobody could help me. 
Also, i've read the debian/macbook page but i couldn't figure it out.


Please help me to fix this as i am choosing Debian as my primary OS.

Thanks a lot.
Ardawan

Systemd: Error when replacing postfix LSB init with postfix.service on Debian 8 (jessie)

[Jonathan de Boyne Pollard]

Sven Hartge:


systemd happily runs "legacy" LSB init scripts

... except when its one-size-fits-all approach does not work, of 
course.  Example:


* https://unix.stackexchange.com/questions/386846/

This is the problem with even Mewburn rc scripts (as I can attest from 
personal experience of writing replacements for an entire Mewburn rc 
system) let alone with van Smoorenburg rc scripts (which are far messier 
than Mewburn rc ones).  One size does not fit all.  One really is not 
going to ever get a backwards-compatibility mechanism that copes with 
all such scripts in the general case "happily".

Systemd: Error when replacing postfix LSB init with postfix.service on Debian 8 (jessie)

[Jonathan de Boyne Pollard]

Tom Browder:


# systemctl enable postfix # systemctl daemon-reload



Minor note: enable incorporates a daemon-reload.

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 12:40, David Wright wrote:

> On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:

>> On 2017-08-24 at 11:43, David Wright wrote:

>>> There are plenty of ways that you, or Debian, can set a default.
>>> But it surprises me that so many people grumble about this
>>> change. The history of computing is littered with statements like
>>> "virtually every computer has exactly one or two NICs".
>> 
>> The thing is, currently that statement[1] *is* correct, so
>> *currently* the default should be suited for that configuration.
>> 
>> If things ever do reach a point where that is no longer the common
>> case, it would then become appropriate to propose changing the
>> default to one suited for that more-complex configuration.
>> 
>> But we are not yet there, or indeed anywhere close to there, so
>> that should not yet be the default.
> 
> By that argument, you wait until lots of people have problems before 
> you change the default to accomodate them, instead of thinking
> ahead.

Well, yes - or at least until lots of people are *about to* have
problems pretty soon, unless the default is changed first. That is at
least preferable to *causing* lots of people to have problems (or at
least experience additional inconvenience) by changing the default too
far in advance.

> If you want a simpler default, can you not follow the instructions 
> and give yourself one.

Er... what?

A default is "what you get if you don't take steps to get something else".

If you have to take steps to achieve a given configuration, by
definition that configuration is not the default.

Thus, since the "old" naming scheme here no longer comes as the default
(for new installs, et cetera), I cannot make it the default.

I can certainly make local changes to get a non-default configuration,
but that does not make that configuration the default.

> For people upgrading, Debian ensured that there would not be an
> unexpected change; the older methods prevail¹.

Missing footnote?

>>> This list is full of postings about the complex DNS system. But
>>> how long did /etc/hosts last?
>> 
>> It's still there and still in use, albeit not as a primary source,
>> last I checked...
> 
> It's the *only* source here for such as 192.168.1.13  wasp but I was
> assuming you'd understand I was talking about non-local hosts on the
> Internet.

Just offhand, I don't think I even remember a time when that file was
used (outside of special one-off cases) for such hosts. I also don't
remember encountering such a special one-off case in the past several
years to a decade, at least, although I wouldn't be at all surprised to
learn they still crop up.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: escritorios sin graficos

[Felix Perez]

El 24 de agosto de 2017, 20:45, Gerardo Diez
 escribió:
>
>
> El 25 ago. 2017 1:34, "Felix Perez"  escribió:
>
> El 24 de agosto de 2017, 17:28, zetam.imap  escribió:
>>
>>
>> On 24/08/17 12:21, José Mateo Ruiz wrote:
>>> Hola Alexlikerock:
>>> Decías el  Miércoles, 23 de Agosto del 2017.
>>>
 Buenas tardes.

 Tengo debia 7 instalado a modo consola, nada de gráficos

 Cómo puedo tener 2 o 3 terminales al mismo tiempo??

 Alguna idea??

 Veo respuestas pero todo en modo gráfico, estoy a como consola sin
 gráficos.

 Agradezco toda ayuda



>>> Mira esta página, http://www.sromero.org/wiki/linux/aplicaciones/tmux
>>
>> Creo que puedes tener hasta 256 terminales por defecto. Como mínimo y
>> por combinaciones de teclas "alt+ctrl+1" al ..+7 accedes a las 7
>> primeras, al resto de ellas no tengo idea cómo.
>>
>> Otra herramienta que podría resultar útil sería screen, apt install
>> screen.
>> saludos
>>
>>
>
>  Hola, prueba terminator, esta en los repos:
>
> Terminator is a little project to produce an efficient way of
> filling a large area of screen space with terminals.
>
> The user can have multiple terminals in one window and use
> key bindings to switch between them. See the manpage for
> details.
>
>
> --
> usuario linux  #274354
> normas de la lista:  http://wiki.debian.org/es/NormasLista
> como hacer preguntas inteligentes:
> http://www.sindominio.net/ayuda/preguntas-inteligentes.html
>
> Lo que pide es _sin entorno gráfico_. Por tanto Terminator no le vale.
>
> Por proponer otra opción: emacs-nox. Lo divides y lanzas una Shell en cada
> buffer.
>
>

Toda la razón, se me pasó ese "pequeño detalle".  Para revisar:
https://www.tecmint.com/linux-terminal-emulators/


Por favor no escribas al privado, gracias.


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

Tails: Failed InRelease - tor+http://vwakviie2ienjx6t.onion/

[Anonymous]

I'm seeing this in Tails when I refresh the package repositories:

Failed - 0B - InRelease - tor+http://vwakviie2ienjx6t.onion/ debian stretch 
InRelease

Why is this happening and how may I fix it please?

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 20:58:18 (-0400), Gene Heskett wrote:
> On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:
> > On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:

> > > The history of computing is littered with statements like
> > > "virtually every computer has exactly one or two NICs".
> >
> > It used to be zero.
> >
> > We are currently in the phase of history where this statement is
> > true. NICs are both ubiquitous and cheap, yet devices tend to
> > come with one (only an ethernet port or only a wifi radio) or
> > two (one of each of those, or a wifi radio and a cell radio).
> >
> > Devices can add more, but they are always special cases: my
> > Debian-running firewall has 5 ethernet ports. I occasionally
> > add a USB ethernet frob in order to isolate a device that I want
> > to talk to directly. Special cases deserve special treatment.
> >
> > I expect the statement to remain true for the next ten years.
> >
> > Do you expect differently? If so, why?
> >
> > > This list is full of postings about the complex DNS system. But
> > > how long did /etc/hosts last? Some complexity is unavoidable,
> > > but if you try to avoid it, you pay for it later. Look at timezones.
> > > Ever allowing computers' internal clocks to run on local time
> > > was, with hindsight, a big mistake. Leap seconds might also
> > > be seen the same way (still under debate).
> >
> > /etc/hosts still acts the way it always did -- put in an entry,
> > it overrides DNS.
> >
> That depends entirely on who wrote your /etc/resolv.conf and whether or 
> not your did a sudo chattr +i /etc/resolv.conf, immediately after 
> verifying that it works. (and of course that implies it is a real file, 
> not a softlink to something else.  With N-M in the mix and active that 
> is the only way to keep it from tearing down your network configuration 
> and leaving you empty files, and no network, if it cannot find a dhcpd 
> server)

(We've heard about your problems concerning /etc/resolv.conf
several times now.)

I think the file that affects the priority of /etc/hosts is
/etc/nsswitch.conf which typically contains a line like:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

But that misses the point I was making, which requires one to know
a fragment of Internet history. /etc/hosts started life as a file
containing the address of every host on the network (then ARPANET).
Simple, sufficient at the time, but obviously not going to stay
the course.

Similarly, /dev/sdX just about works well enough for simple, static
systems but not for more complex, dynamic ones; eth0 likewise is
showing its age for scaling and flexibility, particularly as the
newer scheme adds functionality without removing the legacy.

Cheers,
David.

How to change date and time format for quoting in Thunderbird?

[Mario Castelán Castro]

When replying to a message in Thunderbird as packaged in Debian 9, the
date and time is automatically placed before the quote, like this: “On
22/08/17 17:31, $NAME wrote:”. How can I change the format used for the
date and time? In addition, I want to change the format of $NAME to
include his e-mail address a well.

Thanks.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan



signature.asc
Description: OpenPGP digital signature

Re: Re : Re : problème de tri avec sort

[G2PC]

Le 24/08/2017 à 17:57, Samy Mezani a écrit :
> Le 24/08/2017 à 17:19, nicolas.patr...@gmail.com a écrit :
>> sort trie les lignes selon l’ordre lexicographique de la table ASCII.
>> Regarde les codes ASCII de chaque caractère de chaque ligne.
>> Le premier :
>> 34-97-34-10
>> 34-97-32-98-34-10
>> 34-97-99-34-10
>> 34-97-32-122-34-10
>> Le deuxième :
>> 34-97-32-122-34-64-116-10
>> 34-97-32-98-34-64-116-10
>> 34-97-34-64-116-10
>> 34-97-99-34-64-116-10
>
> Je viens d'essayer de trier le fichier 2 en ôtant au préalable les
> guillemets, voici ce que ça donne :
> 97  32  98  64 116  10
> 97  99  64 116  10
> 97  64 116  10
> 97  32 122  64 116  10
>
> Ça n'a pas l'air d'être dans un ordre lexicographique. C'est ça que je
> ne comprend pas. Pour le fichier 1 pas de souci, mais pour le 2, à
> partir du moment où il y a une 2ème colonne, ça foire…
>
> D'autres pistes ?
>
> Merci
>
> Samy
>
J'ai le même problème, pour classer des lignes d'url par ordre
alphabétique. La source du fichier contient plusieurs lignes, une url
par ligne, qui commence par http:// ou par https://
J'obtiens des tri de ce type, je n'ai pas aboutis pour trier proprement
une liste d'url.
http://abc
https://def
http://bcd

Re: Question to new network device names

[Gene Heskett]

On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:

> On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > There are, of course, five different ways to do this (at a
> > > minimum):
> > >
> > > 1. /dev/sda1 is based on discovery order. Changes in discovery
> > > order may indicate a significant problem that you need to
> > > investigate -- or not.
> >
> > I'm having difficulty imagining a scenario where the identity
> > of sdaX, in particular, is unimportant (for most people).
>
> Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and
> have /dev/sda, b, c and d in an mdadm RAID10.
>
> mdadm will scan all disks looking for its signature, and will
> assemble them into /dev/md/0 regardless of physical disk
> location. So it really won't matter to you whether you have the
> same disks in /dev/sdX from boot to boot as long as they are
> all there.
>
> But for most people, most of the time, swapping /dev/sda and
> /dev/sdc would be a problem.
>
> > But in connection with the original NIC discussion, the absence
> > of disk/by-uuid would be sorely missed if it weren't there, which
> > is why some improvement on eth0, eth1 assignment was needed,
> > and the result was a very flexible system IMO.
> >
> > > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware
> > > RAID -- have their own ideas about what to do and how to do it,
> > > which may include any of the above methods as well as their own
> > > peculiarities.
> > >
> > > That said, if you have a laptop or a desktop with 1-2 disks, you
> > > are probably going to be perfectly happy with either /dev/sda1 or
> > > LABEL=root-$HOSTNAME addressing.
> >
> > With two disks on a BIOS computer, you have an immediate problem,
> > don't you? That what disk-swapping was all about. And that was when
> > everything was on ATA.
>
> On a well-working computer, device discovery order is constant without
> physical changes. sda will always be sda, until it breaks or
> something else (bad) happens.
>
> > But now look at the debates here on, for example, how an SD card
> > is going to appear to the system. The schematic diagram of any
> > laptop looks like a forest of USBs (and other types) so which is
> > going to win the race to become sda?
>
> They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or
> BIOS will become sda. Or if you've got an internal USB port with a
> stick in it, that might be a selected candidate. In no case
> should it change without hardware failure or physical
> rearrangement.
>
> The question is, how will your newly plugged in SD card become
> sdk rather than sdj, and the answer is that mass storage devices
> that are expected to be rearranged should be treated differently
> from those which are expected to always be available from
> boot-time onwards.
>
> > > Getting back to the original point, NIC names -- virtually every
> > > computer has exactly one or two NICs, and is best served by eth0
> > > and wlan0. The computers with 3-5 NICs are usually best served
> > > that way. More complex naming schemes are helpful when you have a
> > > router or switch, and it's nice that Debian supports that, but
> > > hardly a good default.
> >
> > There are plenty of ways that you, or Debian, can set a default.
> > But it surprises me that so many people grumble about this change.
>
> People grumble about changes for several nonexclusive reasons:
>
> 1. The change broke what they were doing.
> 2. The change broke their mental model of what they were doing.
> 3. The change did not bring them perceived benefits.
> 4. The change appears arbitrary.
> 5. The change fixed a problem but they perceive better ways to
>solve the problem.
> 6. The change creates new problems.
>
> > The history of computing is littered with statements like
> > "virtually every computer has exactly one or two NICs".
>
> It used to be zero.
>
> We are currently in the phase of history where this statement is
> true. NICs are both ubiquitous and cheap, yet devices tend to
> come with one (only an ethernet port or only a wifi radio) or
> two (one of each of those, or a wifi radio and a cell radio).
>
> Devices can add more, but they are always special cases: my
> Debian-running firewall has 5 ethernet ports. I occasionally
> add a USB ethernet frob in order to isolate a device that I want
> to talk to directly. Special cases deserve special treatment.
>
> I expect the statement to remain true for the next ten years.
>
> Do you expect differently? If so, why?
>
> > This list is full of postings about the complex DNS system. But
> > how long did /etc/hosts last? Some complexity is unavoidable,
> > but if you try to avoid it, you pay for it later. Look at timezones.
> > Ever allowing computers' internal clocks to run on local time
> > was, with hindsight, a big mistake. Leap seconds might also
> > be seen the same way (still under debate).
>
> /etc/hosts still acts the way it always did 

Re: One-line password generator

[David Wright]

On Thu 24 Aug 2017 at 18:42:47 (+0100), Brian wrote:
> On Wed 23 Aug 2017 at 18:06:49 -0500, Mario Castelán Castro wrote:
> > On 23/08/17 14:11, Brian wrote:

> > > "Probably" is probably good enough. The probability of either of the two
> > > previous passwords being deduced from pure guessing is close to zero.
> >
> > It is not human guessing, but brute force attacks with specialized
> > hardware what you should try to protect against.

[...]

> > Anyway, you have to take into account that sometimes a data base of
> > hashed passwords of the users can be  obtained through normal cracking.
> > Then the attacker can perform a brute force search without any further
> > need for network access.
> > 
> > If your ~/.gnupg directory leaks, then your OpenPGP key is protected
> > only by your password. No network access is required after the initial leak.
> 
> I'll give you that. 50,000 tests per second offline (or whatever it is
> now) beats an online attack of a few hundred (?) per second any day of
> the week.
> 
> I've seen it said that a memorable password is a weak password. Perhaps
> there is some truth in that, but (again IME) it needn't be so.

Unless you have accounts¹ that invite break-in attempts², the main
thing to resist offline cracking is to have better passwords than
your neighbours, just like security against burglary. Once a suitable
proportion of passwords have been cracked, which will consist of the
easier ones, there are diminishing returns in continuing to try to
crack the rest.

¹accounts of all sorts, not just forums.
²institutions, slebs, politicians, etc.

Cheers,
David.

[no subject]

[max vidocq]

   Bonjour Angelique
Les acteurs en chantier. Si la fin des travaux de gros oeuvre peut étre située 
en 1269, un autre millésime est porté sur la pierre centrale du labyrinthe. 
Véritable pierre commémorative, dont l' original posé en 1288 est aujourd ' hui 
conservé au musée, elle marque l' achèvement de la cathédrale et porte les noms 
des principaux acteurs du chantier. Ouvert en 1220 à l' initiative de l' évèque 
Evrard de Fouilloy 1211-1222, celui-ci est conduit par trois maitres d' oeuvre 
successifs, le premier étant Robert de Luzarches, sans doute originaire d' 
lle-de-France, remplacé par Thomas puis RenauD ce Cormont probablement natifs 
de Picardie. Si l' on ne sait rien de leur formation, la plupart des historiens 
de l' art s' accordent pour attribuer le projet initial et le parti pris 
esthétique de Notre-Dame d' Amiens à Robert de Luzarches. Mème s' il meurt 
assez rapidement, c' est lui qui fixe l' organisation des porches de la façade 
occidentale et met en oeuvre les fondations. ll a aussi le temps de construire 
une grande partie de la nef, dont il réalise les piles et fixe l' élévation à 
trois niveaux. Pour les bas-cotés du choeur, son empreinte se limite sans doute 
aux soubassements. Thomas de Cormont poursuit l' oeuvre, méme si son role est 
plus difficile à définir dans une période intermédiaire. ll est toutefois assez 
probable qu' il participe à l' achèvement de la totalité de la nef et des 
parties basses du choeur. L' arrviée de son fils Renaud annonce des changements 
stylistiques. S' il est avéré qu' il réside dans une maison du quartier en 
1260, on ne sait pas exactement quand il prend la direction du chantier. 
Néanmoins,  on estime que durant près de trente ans, c' est lui qui méme à son 
terme l' édification de Notre-Dame d' Amiens. Engagée sous le règne de Philippe 
Auguste, elle se déroule principalement durant le règne de Saint Louis, dans un 
temps de prospérité économique pour la ville, le chapitre de la cathédrale 
jouissant du prestige de la relique du chef de saint Jean-Baptiste, rapportée 
en 1206 par Wallon de Sarton, chanoine de Picquigny.
 Max




0ç


Envoyé à partir d’Outlook

Re: escritorios sin graficos

[Gerardo Diez]

El 25 ago. 2017 1:34, "Felix Perez"  escribió:

El 24 de agosto de 2017, 17:28, zetam.imap  escribió:
>
>
> On 24/08/17 12:21, José Mateo Ruiz wrote:
>> Hola Alexlikerock:
>> Decías el  Miércoles, 23 de Agosto del 2017.
>>
>>> Buenas tardes.
>>>
>>> Tengo debia 7 instalado a modo consola, nada de gráficos
>>>
>>> Cómo puedo tener 2 o 3 terminales al mismo tiempo??
>>>
>>> Alguna idea??
>>>
>>> Veo respuestas pero todo en modo gráfico, estoy a como consola sin
gráficos.
>>>
>>> Agradezco toda ayuda
>>>
>>>
>>>
>> Mira esta página, http://www.sromero.org/wiki/linux/aplicaciones/tmux
>
> Creo que puedes tener hasta 256 terminales por defecto. Como mínimo y
> por combinaciones de teclas "alt+ctrl+1" al ..+7 accedes a las 7
> primeras, al resto de ellas no tengo idea cómo.
>
> Otra herramienta que podría resultar útil sería screen, apt install
screen.
> saludos
>
>

 Hola, prueba terminator, esta en los repos:

Terminator is a little project to produce an efficient way of
filling a large area of screen space with terminals.

The user can have multiple terminals in one window and use
key bindings to switch between them. See the manpage for
details.


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

Lo que pide es _sin entorno gráfico_. Por tanto Terminator no le vale.

Por proponer otra opción: emacs-nox. Lo divides y lanzas una Shell en cada
buffer.

Re: escritorios sin graficos

[Felix Perez]

El 24 de agosto de 2017, 17:28, zetam.imap  escribió:
>
>
> On 24/08/17 12:21, José Mateo Ruiz wrote:
>> Hola Alexlikerock:
>> Decías el  Miércoles, 23 de Agosto del 2017.
>>
>>> Buenas tardes.
>>>
>>> Tengo debia 7 instalado a modo consola, nada de gráficos
>>>
>>> Cómo puedo tener 2 o 3 terminales al mismo tiempo??
>>>
>>> Alguna idea??
>>>
>>> Veo respuestas pero todo en modo gráfico, estoy a como consola sin 
>>> gráficos.
>>>
>>> Agradezco toda ayuda
>>>
>>>
>>>
>> Mira esta página, http://www.sromero.org/wiki/linux/aplicaciones/tmux
>
> Creo que puedes tener hasta 256 terminales por defecto. Como mínimo y
> por combinaciones de teclas "alt+ctrl+1" al ..+7 accedes a las 7
> primeras, al resto de ellas no tengo idea cómo.
>
> Otra herramienta que podría resultar útil sería screen, apt install screen.
> saludos
>
>

 Hola, prueba terminator, esta en los repos:

Terminator is a little project to produce an efficient way of
filling a large area of screen space with terminals.

The user can have multiple terminals in one window and use
key bindings to switch between them. See the manpage for
details.


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

Re: Problemas con pentaho y tomcat

[Felix Perez]

El 24 de agosto de 2017, 15:18, Romero, Fernando
 escribió:
> Hola como están, tengo un problema con tomcat.
> Instale pentaho y me instalo tomcat, pero no puedo levantar la web de 
> pentaho, me da error "Estado HTTP 404 - "
> Estuve buscando en la web de pentaho pero nada de lo da como solución ahí me 
> funciono, alguien tuvo el mismo problema?
>

Hola, das muy poca información.
revisaste esto:
http://forums.pentaho.com/showthread.php?151900-HTTP-Status-404-please-help



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

[no subject]

[max vidocq]

Bonjour Angelique
Amiens, le pays de l' or bleu. Au xllle siècle, avec la mode du bleu, la 
teinture textile fait la fortune des marchands waidiers. Les feuilles de la 
guède, plante cultivée dans les environs, sont recueillies à la main et broyées 
encore fraiches. La pate pastel est sesuite moulée en pains plus séchée. 
Rassemblées à Amiens, ces coques pays de cocagne enrichissent teinturiers 
locaux et négociants jusqu' à la guerre de Cent Ans. Déplacée dans le 
Sud-Ouest, l' activité sera ensuite concurrencée par l' indigo.
La chapelle des Macchabées. Peut-étre en raison d' un ancien décor de danse 
macabre, ou plus simplement pour sa proximité du cimetière des chanoines, la 
salle capitulaire est de nos jours encore appelée chapelle des Macchabées. Elle 
est desservie par quelques travées de cloitre, en grande partie refaites par 
Eugène Viollet-le-Duc, auquel on doit la maison du chanoine gardien du trésor. 
Avant son démantèlement, le cloitre contournait le chevet, reliant ainsi les 
deux chapelles rayonnantes les plus éloignées.
1. Vu ici du triforium du bras nord du transept, le labyrinthe a été refait en 
1884, comme l' ensemble du dallage, sous la direction de Juste Lisch, 
architecte élève de Viollet-le-Duc.
2. La pierre située au centre du labyrinthe a valeur de pierre commémorative.
3. Le gisant de l' évèque Goeffroy d' Eu 1222-1236.
4. Sur plan barlong, chaque travée de la nef est voutée sur croisée d' ogives. 
L' ouverture pratiquée dans un des voutains permet le passage d' un 
monte-charge actionné par une chèvre, appareil de levage situé dans le comble, 
voir page 30.
5. Aimé et Louis Duthoit. Amiens: la sacristie et la chapelle des Macchabées au 
sud-est de la cathédrale vers 1850. Encre sur papier transparent collé sur 
papier blanc.
  Max


Envoyé à partir d’Outlook

Re: DHCP server that itself gets an IP address by DHCP

[Mark Fletcher]

On Thu, Aug 24, 2017 at 04:39:13PM -0400, Greg Wooledge wrote:
> On Thu, Aug 24, 2017 at 10:21:04PM +0200, Pascal Hambourg wrote:
> > Le 24/08/2017 à 11:30, Reco a écrit :
> > > 
> > > Somewhat hackish, but straightforward way to achieve this is to redirect
> > > DNS requests from your LAN to correct DNS. Something like this should do
> > > the trick:
> > 
> > Not so straightforward because you still need to get the ISP's DNS and
> > update the iptables rules whenever the DNS change.
> 
> I strongly recommend just running your own caching DNS resolver on the
> DHCP server host.  ISP nameservers are often slow and unreliable.
> 

OK, thanks for the advice. One possibly stupid question though... 
whenever a DNS server running on my own firewall doesn't have an answer 
to a DHCP query, it is going to broadcast it out... to the ISP's DNS 
servers, no? So I'm not actually getting away from the ostensibly slow 
(which I could easily believe) and/or unreliable (which I've never seen 
evidence of) ISP DNS servers, just by installing my own.

I suppose I could override my resolv.conf somehow on my firewall machine 
to use DNS servers regarded as fast and reliable. But I doubt any of 
those are physically close to me here in Japan -- eg Google's are no 
doubt in the US, about as far away from me as it is possible to get 
while still being on planet Earth. Hard to imagine that is going to be 
faster. Or am I missing the point?

And, in terms of a local caching DNS server -- would BIND be the 
recommended solution?

Thanks

Mark

Re: Re: USB wireless keyboard in stretch

[Alle Meije Wink]

Hi Zoltan,

Thanks for all your suggestions

I looked at the .xcfe logs but they did not mention the keyboard or mouse.
Also, xfce4-goodies was already installed

Touching wood it seems the problem is fixed now.
Following

http://tutorialforlinux.com/2017/01/18/how-to-switch-from-gnomegnome3-to-xfce-desktop-on-debian-8-jessie
I set up XFCE with the slim display manager.
That made the keyboard and mouse work again -- I think something had gone
wrong in the lightdm configuration.
After that I removed and re-installed lightdm and can now start that again
with mouse and keyboard as well.

Not sure what was wrong which is a bit of a shame.
Good to have it working again though...

Re: DHCP server that itself gets an IP address by DHCP

[Mark Fletcher]

On Thu, Aug 24, 2017 at 11:35:25PM +0300, Reco wrote:
> On Thu, 24 Aug 2017 22:21:04 +0200
> Pascal Hambourg  wrote:
> 
> > Le 24/08/2017 à 11:30, Reco a écrit :
> > > 
> > > Somewhat hackish, but straightforward way to achieve this is to redirect
> > > DNS requests from your LAN to correct DNS. Something like this should do
> > > the trick:
> > 
> > Not so straightforward because you still need to get the ISP's DNS and 
> > update the iptables rules whenever the DNS change.
> 
> Appropriate dhclient hook should do this trick.
> I'd start with copying and modifying resolvconf one.
> 
> 

I think the concept of "appropriate dhclient hook" might be exactly what 
I was after -- could an "appropriate dhclient hook" perhaps be used to 
update the name servers being offered by the DHCP server? And would that 
be done by updating dhcp.conf and restarting the dhcp server, or would 
that cause other problems?

And, is dhclient a separate piece of software from systemd.networkd? 
Because I am using the latter at the moment to get the IP address from 
the ISP on the firewall machine, although I am not married to that 
method, it's just that it was super-easy to set up and worked first 
time, so I never had reason to look for an alternative.

Mark

Re: Debian v9 it's a stretch

[Dejan Jocic]

On 24-08-17, Brian wrote:
> On Thu 24 Aug 2017 at 21:56:51 +0200, Dejan Jocic wrote:
> 
> > On 24-08-17, Brian wrote:
> > > On Thu 24 Aug 2017 at 21:31:55 +0200, Dejan Jocic wrote:
> > > 
> > > > On 24-08-17, Brian wrote:
> > > > > On Thu 24 Aug 2017 at 21:16:26 +0200, Dejan Jocic wrote:
> > > > > 
> > > > > > On 24-08-17, Brian wrote:
> > > > > > > > The alternative would be to reconfigure rkhunter.
> > > > > > > 
> > > > > > > You could make a start by purging it from your system. It 
> > > > > > > performs no
> > > > > > > useful function.
> > > > > > > 
> > > > > > > -- 
> > > > > > > Brian.
> > > > > > > 
> > > > > > 
> > > > > > Could you explain that bit more, please?
> > > > > 
> > > > > apt-get purge rkhunter. Enough?
> > > > > 
> > > > 
> > > > No, not really. Why do you think that rkhunter is useless?
> > > 
> > > It does not anything of consequence.
> > > 
> > > -- 
> > > Brian
> > > 
> > 
> > Do you find checking for possible rootkits is useless, or you are just
> > not happy how rkhunter performs that function?
> 
> A well-documented case of rkhunter discovering a rootkit in the last
> ten years (the 1000s of false positives do not count) would go a long
> way to establishing its credence,
> 

So, those in security/forensics who recommend use of rkhunter have just
been silly? Interesting. But think that I'll use it anyway, just to be
on the safe side. It does not hurt.

Re: Debian v9 it's a stretch

[Brian]

On Thu 24 Aug 2017 at 21:56:51 +0200, Dejan Jocic wrote:

> On 24-08-17, Brian wrote:
> > On Thu 24 Aug 2017 at 21:31:55 +0200, Dejan Jocic wrote:
> > 
> > > On 24-08-17, Brian wrote:
> > > > On Thu 24 Aug 2017 at 21:16:26 +0200, Dejan Jocic wrote:
> > > > 
> > > > > On 24-08-17, Brian wrote:
> > > > > > > The alternative would be to reconfigure rkhunter.
> > > > > > 
> > > > > > You could make a start by purging it from your system. It performs 
> > > > > > no
> > > > > > useful function.
> > > > > > 
> > > > > > -- 
> > > > > > Brian.
> > > > > > 
> > > > > 
> > > > > Could you explain that bit more, please?
> > > > 
> > > > apt-get purge rkhunter. Enough?
> > > > 
> > > 
> > > No, not really. Why do you think that rkhunter is useless?
> > 
> > It does not anything of consequence.
> > 
> > -- 
> > Brian
> > 
> 
> Do you find checking for possible rootkits is useless, or you are just
> not happy how rkhunter performs that function?

A well-documented case of rkhunter discovering a rootkit in the last
ten years (the 1000s of false positives do not count) would go a long
way to establishing its credence,

Re: Limitação do comando 'date' ?

[Tiago Pigazao]

Ok obrigado pela observação

Em 24 de agosto de 2017 15:18, Linux - Junior Polegato <
li...@juniorpolegato.com.br> escreveu:

> Olá!
>
> Não é um bug, pois o "date" converte para a data local no timezone
> do sistema quanto não especificado um, e a hora é "00:00:00" quando não
> especificado também.
>
> Como não existiu essa data e horário no seu sistema, que creio ser
> tal com o meu timezone (cat /etc/timezone => America/Sao_Paulo), informa
> que data é inválida, pois realmente é, visto que "2010/10/17 00:00:00 -02"
> a "2010/10/17 00:59:59 -02" não existiu no nosso timezone.
>
> Assim sendo pode usar a opção "-u" do "date" para resolver, pois
> existiu "2010/10/17 00:00:00 UTC" (UTC = 00).
>
> --
>
> []'s
>
> Junior Polegato
>
>
>
> Em 24-08-2017 15:00, Tiago Pigazao escreveu:
>
> Excelente  justamente o teste que não fiz , que foi especificando a hora !
> , para o que pretendo ja vai ajudar bastante
> de qualquer forma fica o registro do Bug
>
> Obrigado pessoal
>
> Em 24 de agosto de 2017 14:01, Paulino Kenji Sato 
> escreveu:
>
>> Ola,
>> Parece ser um bug relacionado com o horário de verão.
>> Mesmo problema com a data 15 de Outubro de 2017, que e o inicio do
>> horário de verão deste ano.
>> date (GNU coreutils) 8.13
>> Acrescentando o fuso horário ou uma hora que não seja 00:mm:ss retorna a
>> data.
>>
>>
>>
>> 2017-08-24 13:07 GMT-03:00 Tiago Pigazao :
>>
>>> Bom dia,
>>>
>>> Pessoal, ao fazer alguns testes aqui percebi que o comando date não
>>> reconhece algumas datas por ex:
>>>
>>> quando passo uma determinada data ele deve me retornar o dia da semana,
>>> o dia , mês.., usando o parâmetro '-d'  , o que ocorre é que, quando vou
>>> testar uma determinada data ele me retorna como *data* *invalida *, e
>>> da erro no comando como se fosse a sintaxe errada:
>>>
>>> data que apresentou o problema: (esse dia realmente existe)
>>>
>>> date -d 2010/10/17
>>>
>>> ja tentei mudar a string também como:
>>>
>>> date -d '17 oct 2010'
>>>
>>>
>>> se eu colocar um dia anterior ou posterior , ele funciona sem problemas
>>> , me retornando a saída esperada (dia da semana e etc..):
>>>
>>> date -d 2010/10/16
>>> date -d '16 oct 2010'
>>>
>>> date -d 2010/10/18
>>> date -d '18 oct 2010'
>>>
>>>
>>> outras datas que apresentaram o mesmo efeito, por ex:
>>>
>>> 2000/10/08
>>> 2004/11/02
>>> 2009/10/18
>>>
>>> a questão é isso Seria uma limitação do date ou eu teria que especificar
>>> um parâmetro adicional para a saída esperada ?
>>>
>>>
>

Re: escritorios sin graficos

[zetam.imap]

On 24/08/17 12:21, José Mateo Ruiz wrote:
> Hola Alexlikerock:
> Decías el  Miércoles, 23 de Agosto del 2017.
>
>> Buenas tardes.
>>
>> Tengo debia 7 instalado a modo consola, nada de gráficos
>>
>> Cómo puedo tener 2 o 3 terminales al mismo tiempo??
>>
>> Alguna idea??
>>
>> Veo respuestas pero todo en modo gráfico, estoy a como consola sin 
>> gráficos.
>>
>> Agradezco toda ayuda
>>
>>
>>
> Mira esta página, http://www.sromero.org/wiki/linux/aplicaciones/tmux

Creo que puedes tener hasta 256 terminales por defecto. Como mínimo y
por combinaciones de teclas "alt+ctrl+1" al ..+7 accedes a las 7
primeras, al resto de ellas no tengo idea cómo.

Otra herramienta que podría resultar útil sería screen, apt install screen.
saludos
 

Re: Stretch vim doesnt cut and paste

[Reco]

Hi.

On Thu, 24 Aug 2017 21:59:36 +0200
Elimar Riesebieter  wrote:

> * Reco  [2017-08-24 18:16 +0300]:
> 
> [...]
> > vim(1) does not mention defaults.vim, so it must be a case of obsolete
> > documentation.
> > That, and I'm too lazy to view vim source.
> 
> Read file:///usr/share/doc/vim-common/NEWS.Debian.gz

Thanks. That reminds me to reinstall apt-listchanges which I should've
done *before* upgrading to stretch.

Reco

Re: DHCP server that itself gets an IP address by DHCP

[Greg Wooledge]

On Thu, Aug 24, 2017 at 10:21:04PM +0200, Pascal Hambourg wrote:
> Le 24/08/2017 à 11:30, Reco a écrit :
> > 
> > Somewhat hackish, but straightforward way to achieve this is to redirect
> > DNS requests from your LAN to correct DNS. Something like this should do
> > the trick:
> 
> Not so straightforward because you still need to get the ISP's DNS and
> update the iptables rules whenever the DNS change.

I strongly recommend just running your own caching DNS resolver on the
DHCP server host.  ISP nameservers are often slow and unreliable.

Re: DHCP server that itself gets an IP address by DHCP

[Reco]

Hi.

On Thu, 24 Aug 2017 22:21:04 +0200
Pascal Hambourg  wrote:

> Le 24/08/2017 à 11:30, Reco a écrit :
> > 
> > Somewhat hackish, but straightforward way to achieve this is to redirect
> > DNS requests from your LAN to correct DNS. Something like this should do
> > the trick:
> 
> Not so straightforward because you still need to get the ISP's DNS and 
> update the iptables rules whenever the DNS change.

Appropriate dhclient hook should do this trick.
I'd start with copying and modifying resolvconf one.


> > iptables -t nat -A OUTPUT -i  -p udp --dport 53 \
> > -j DNAT --to-destination :53
> > 
> > iptables -t nat -A OUTPUT -i  -p tcp --dport 53 \
> > -j DNAT --to-destination :53
> 
> You mean "-A PREROUTING".

My mistake indeed. OUTPUT is unsuitable here.

Reco

[Updated] How To Fix: Firewire IRQ Errors on Reboot

[RavenLX]

I've had problems with my ThinkPad T61 Freezing on me (wouldn't respond 
to keyboard, mouse, nothing). So I reinstalled Debian without the tlp or 
sensors stuff. I was back to the old IRQ problems (which turned into 
FIFO overrun errors if I put irqpoll in GRUB). It was just a constant 
cycle of problems. I finally fixed the errors but the computer is 
running quite sluggish now (and I haven't used it enough since to see if 
it was going to freeze or not - probably won't again as I'll just use it 
as a backup system in case my main system goes down).


Anyway, here's how to fix:

Computer: IBM/Lenovo ThinkPad T61 Laptop
OS: Debian 9 (Stretch):

Linux t61 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) 
x86_64 GNU/Linux


Problems:

[   11.413790] [drm:i965_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
underrun
[   11.678293] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on 
minor 0

[   12.374019] i915 :00:02.0: fb0: inteldrmfb frame buffer device

[   11.070526] [drm] Initialized
[   11.393344] [drm] Memory usable by graphics device = 512M
[   11.393348] [drm] Replacing VGA console driver
[   11.408922] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   11.408924] [drm] Driver supports precise vblank timestamp query.
[   11.413790] [drm:i965_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
underrun

[   11.672907] [drm] RC6 disabled, disabling runtime PM support
[   11.672927] [drm] initialized overlay support
[   11.678293] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on 
minor 0

[   11.743594] fbcon: inteldrmfb (fb0) is primary device
[   12.374019] i915 :00:02.0: fb0: inteldrmfb frame buffer device

Fix:

1. Download the BIOS Update ISO from here if you do not have the latest 
BIOS. To test to see if you do:


$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
7LETD0WW (2.30 )
02/27/2012

2.30 is the latest. If you don't have it, get it here:

http://support.lenovo.com/us/en/downloads/migr-67989

2. Burn the ISO to a CD-ROM. I tried putting this on a USB stick and 
while the ThinkPad can boot from USB, it will NOT boot this particular 
ISO from USB. The ReadMe that goes with it also states as such. So it 
must be a CD-ROM.


3. Boot the CD-ROM and update the BIOS.

4. Edit /etc/default/grub so that the following line is as shown:

/etc/default/grub: GRUB_CMDLINE_LINUX="irqpoll nomodeset"

irqpoll is right after all, apparently. And nomodeset will remove the 
underrun error.


I hope this helps some folks or gives a clue as to what could be going 
wrong. If the laptop freezes and goes unresponsive again, I'll have to 
do a hard reset (holding the Power button down until it shuts off - can 
take 10 or more seconds for that to happen) and then dmesg to see what 
went wrong. But for now, this seems to at least get rid of all the errors.

Re: DHCP server that itself gets an IP address by DHCP

[Pascal Hambourg]

Le 24/08/2017 à 11:30, Reco a écrit :


Somewhat hackish, but straightforward way to achieve this is to redirect
DNS requests from your LAN to correct DNS. Something like this should do
the trick:


Not so straightforward because you still need to get the ISP's DNS and 
update the iptables rules whenever the DNS change.



iptables -t nat -A OUTPUT -i  -p udp --dport 53 \
-j DNAT --to-destination :53

iptables -t nat -A OUTPUT -i  -p tcp --dport 53 \
-j DNAT --to-destination :53


You mean "-A PREROUTING".

mijn e-mails

[wilfried martens]

Schrijf me maar uit, a.u.b. 

Re: Stretch vim doesnt cut and paste

[Elimar Riesebieter]

* Reco  [2017-08-24 18:16 +0300]:

[...]
> vim(1) does not mention defaults.vim, so it must be a case of obsolete
> documentation.
> That, and I'm too lazy to view vim source.

Read file:///usr/share/doc/vim-common/NEWS.Debian.gz

Elimar
-- 
  Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)

Re: Debian v9 it's a stretch

[Dejan Jocic]

On 24-08-17, Brian wrote:
> On Thu 24 Aug 2017 at 21:31:55 +0200, Dejan Jocic wrote:
> 
> > On 24-08-17, Brian wrote:
> > > On Thu 24 Aug 2017 at 21:16:26 +0200, Dejan Jocic wrote:
> > > 
> > > > On 24-08-17, Brian wrote:
> > > > > > The alternative would be to reconfigure rkhunter.
> > > > > 
> > > > > You could make a start by purging it from your system. It performs no
> > > > > useful function.
> > > > > 
> > > > > -- 
> > > > > Brian.
> > > > > 
> > > > 
> > > > Could you explain that bit more, please?
> > > 
> > > apt-get purge rkhunter. Enough?
> > > 
> > 
> > No, not really. Why do you think that rkhunter is useless?
> 
> It does not anything of consequence.
> 
> -- 
> Brian
> 

Do you find checking for possible rootkits is useless, or you are just
not happy how rkhunter performs that function?

Re: Debian v9 it's a stretch

[Brian]

On Thu 24 Aug 2017 at 21:31:55 +0200, Dejan Jocic wrote:

> On 24-08-17, Brian wrote:
> > On Thu 24 Aug 2017 at 21:16:26 +0200, Dejan Jocic wrote:
> > 
> > > On 24-08-17, Brian wrote:
> > > > On Thu 24 Aug 2017 at 15:44:30 +0200, Rob van der Putten wrote:
> > > > 
> > > > > Hi there
> > > > > 
> > > > > 
> > > > > On 24/08/17 15:39, Dan Ritter wrote:
> > > > > 
> > > > > >As of Stretch, the standard OpenSSH sshd does not support
> > > > > >Protocol 1, so there's no particular reason to enforce it
> > > > > >by stating Protocol 2.
> > > > > 
> > > > > I assumed as much. It's just a simple way to keep rkhunter happy.
> > > > > 
> > > > > >PermitRootLogin now defaults to "prohibit-password", which
> > > > > >means that you can log in as root with a proper SSH key or
> > > > > >via other methods you have set up, but not with a password.
> > > > > >Another useful argument is forced-commands-only, which requires
> > > > > >both public-key authentication and a command="blah blah" option
> > > > > >in the authorized_keys file, and only allows those commands to
> > > > > >be run. If you've got a pull backup system, that can help.
> > > > > 
> > > > > The alternative would be to reconfigure rkhunter.
> > > > 
> > > > You could make a start by purging it from your system. It performs no
> > > > useful function.
> > > > 
> > > > -- 
> > > > Brian.
> > > > 
> > > 
> > > Could you explain that bit more, please?
> > 
> > apt-get purge rkhunter. Enough?
> > 
> 
> No, not really. Why do you think that rkhunter is useless?

It does not anything of consequence.

-- 
Brian

Re: Debian v9 it's a stretch

[Dejan Jocic]

On 24-08-17, Brian wrote:
> On Thu 24 Aug 2017 at 21:16:26 +0200, Dejan Jocic wrote:
> 
> > On 24-08-17, Brian wrote:
> > > On Thu 24 Aug 2017 at 15:44:30 +0200, Rob van der Putten wrote:
> > > 
> > > > Hi there
> > > > 
> > > > 
> > > > On 24/08/17 15:39, Dan Ritter wrote:
> > > > 
> > > > >As of Stretch, the standard OpenSSH sshd does not support
> > > > >Protocol 1, so there's no particular reason to enforce it
> > > > >by stating Protocol 2.
> > > > 
> > > > I assumed as much. It's just a simple way to keep rkhunter happy.
> > > > 
> > > > >PermitRootLogin now defaults to "prohibit-password", which
> > > > >means that you can log in as root with a proper SSH key or
> > > > >via other methods you have set up, but not with a password.
> > > > >Another useful argument is forced-commands-only, which requires
> > > > >both public-key authentication and a command="blah blah" option
> > > > >in the authorized_keys file, and only allows those commands to
> > > > >be run. If you've got a pull backup system, that can help.
> > > > 
> > > > The alternative would be to reconfigure rkhunter.
> > > 
> > > You could make a start by purging it from your system. It performs no
> > > useful function.
> > > 
> > > -- 
> > > Brian.
> > > 
> > 
> > Could you explain that bit more, please?
> 
> apt-get purge rkhunter. Enough?
> 

No, not really. Why do you think that rkhunter is useless?

Re: Debian v9 it's a stretch

[Brian]

On Thu 24 Aug 2017 at 21:16:26 +0200, Dejan Jocic wrote:

> On 24-08-17, Brian wrote:
> > On Thu 24 Aug 2017 at 15:44:30 +0200, Rob van der Putten wrote:
> > 
> > > Hi there
> > > 
> > > 
> > > On 24/08/17 15:39, Dan Ritter wrote:
> > > 
> > > >As of Stretch, the standard OpenSSH sshd does not support
> > > >Protocol 1, so there's no particular reason to enforce it
> > > >by stating Protocol 2.
> > > 
> > > I assumed as much. It's just a simple way to keep rkhunter happy.
> > > 
> > > >PermitRootLogin now defaults to "prohibit-password", which
> > > >means that you can log in as root with a proper SSH key or
> > > >via other methods you have set up, but not with a password.
> > > >Another useful argument is forced-commands-only, which requires
> > > >both public-key authentication and a command="blah blah" option
> > > >in the authorized_keys file, and only allows those commands to
> > > >be run. If you've got a pull backup system, that can help.
> > > 
> > > The alternative would be to reconfigure rkhunter.
> > 
> > You could make a start by purging it from your system. It performs no
> > useful function.
> > 
> > -- 
> > Brian.
> > 
> 
> Could you explain that bit more, please?

apt-get purge rkhunter. Enough?

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 12:30:37 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > There are, of course, five different ways to do this (at a
> > > minimum):
> > > 
> > > 1. /dev/sda1 is based on discovery order. Changes in discovery order
> > > may indicate a significant problem that you need to investigate -- or not.
> > 
> > I'm having difficulty imagining a scenario where the identity
> > of sdaX, in particular, is unimportant (for most people).
↑↑↑

> Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and 
> have /dev/sda, b, c and d in an mdadm RAID10. 
> 
> mdadm will scan all disks looking for its signature, and will
> assemble them into /dev/md/0 regardless of physical disk
> location. So it really won't matter to you whether you have the
> same disks in /dev/sdX from boot to boot as long as they are
> all there.
> 
> But for most people, most of the time, swapping /dev/sda and
> /dev/sdc would be a problem.

Yes, I assumed that *most* people boot from sda.

> > But in connection with the original NIC discussion, the absence
> > of disk/by-uuid would be sorely missed if it weren't there, which
> > is why some improvement on eth0, eth1 assignment was needed,
> > and the result was a very flexible system IMO.
> > 
> > > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> > > have their own ideas about what to do and how to do it, which may include
> > > any of the above methods as well as their own peculiarities.
> > > 
> > > That said, if you have a laptop or a desktop with 1-2 disks, you
> > > are probably going to be perfectly happy with either /dev/sda1 or
> > > LABEL=root-$HOSTNAME addressing.
> > 
> > With two disks on a BIOS computer, you have an immediate problem,
> > don't you? That what disk-swapping was all about. And that was when
> > everything was on ATA.
> 
> On a well-working computer, device discovery order is constant without
> physical changes. sda will always be sda, until it breaks or
> something else (bad) happens.

Passing comment: our memories are short. I remember the time when the
sole disk in a machine would vacillate between hda and sda if one was
running (as I always do) two consecutive versions of Debian. A
different cause, however.

I haven't looked back to see the number of screams. I'd left
debian-user by then on the grounds of traffic volume.

> > But now look at the debates here on, for example, how an SD card
> > is going to appear to the system. The schematic diagram of any laptop
> > looks like a forest of USBs (and other types) so which is going to win
> > the race to become sda?
> 
> They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or BIOS
> will become sda. Or if you've got an internal USB port with a
> stick in it, that might be a selected candidate. In no case
> should it change without hardware failure or physical
> rearrangement.
> 
> The question is, how will your newly plugged in SD card become
> sdk rather than sdj, and the answer is that mass storage devices
> that are expected to be rearranged should be treated differently 
> from those which are expected to always be available from
> boot-time onwards.

You just made an assumption that does not match my reality, and
you didn't even realize that you made it. :) The SD card may
already be plugged in and contain the OS itself.

But seriously, the only point I'm trying to make here is that even the
single disk computer user should not rely on /dev/sdX names. When they
buy a new disk with perhaps a new technology, or have a failing drive
and want to copy at device-level (ie dd-style), that's precisely not
the time to be distracted by coping with hardware races and shifting
device names.

> > > Getting back to the original point, NIC names -- virtually every computer
> > > has exactly one or two NICs, and is best served by eth0 and wlan0. The
> > > computers with 3-5 NICs are usually best served that way. More complex
> > > naming schemes are helpful when you have a router or switch, and it's
> > > nice that Debian supports that, but hardly a good default.
> > 
> > There are plenty of ways that you, or Debian, can set a default.
> > But it surprises me that so many people grumble about this change.
> 
> People grumble about changes for several nonexclusive reasons:
> 
> 1. The change broke what they were doing.
> 2. The change broke their mental model of what they were doing.
> 3. The change did not bring them perceived benefits.
> 4. The change appears arbitrary.
> 5. The change fixed a problem but they perceive better ways to
>solve the problem.
> 6. The change creates new problems.

Summarising, people will grumble.

> > The history of computing is littered with statements like
> > "virtually every computer has exactly one or two NICs".
> 
> It used to be zero.
> 
> We are currently in the 

Re: Debian v9 it's a stretch

[Dejan Jocic]

On 24-08-17, Brian wrote:
> On Thu 24 Aug 2017 at 15:44:30 +0200, Rob van der Putten wrote:
> 
> > Hi there
> > 
> > 
> > On 24/08/17 15:39, Dan Ritter wrote:
> > 
> > >As of Stretch, the standard OpenSSH sshd does not support
> > >Protocol 1, so there's no particular reason to enforce it
> > >by stating Protocol 2.
> > 
> > I assumed as much. It's just a simple way to keep rkhunter happy.
> > 
> > >PermitRootLogin now defaults to "prohibit-password", which
> > >means that you can log in as root with a proper SSH key or
> > >via other methods you have set up, but not with a password.
> > >Another useful argument is forced-commands-only, which requires
> > >both public-key authentication and a command="blah blah" option
> > >in the authorized_keys file, and only allows those commands to
> > >be run. If you've got a pull backup system, that can help.
> > 
> > The alternative would be to reconfigure rkhunter.
> 
> You could make a start by purging it from your system. It performs no
> useful function.
> 
> -- 
> Brian.
> 

Could you explain that bit more, please?

Re: Debian v9 it's a stretch

[Brian]

On Thu 24 Aug 2017 at 15:44:30 +0200, Rob van der Putten wrote:

> Hi there
> 
> 
> On 24/08/17 15:39, Dan Ritter wrote:
> 
> >As of Stretch, the standard OpenSSH sshd does not support
> >Protocol 1, so there's no particular reason to enforce it
> >by stating Protocol 2.
> 
> I assumed as much. It's just a simple way to keep rkhunter happy.
> 
> >PermitRootLogin now defaults to "prohibit-password", which
> >means that you can log in as root with a proper SSH key or
> >via other methods you have set up, but not with a password.
> >Another useful argument is forced-commands-only, which requires
> >both public-key authentication and a command="blah blah" option
> >in the authorized_keys file, and only allows those commands to
> >be run. If you've got a pull backup system, that can help.
> 
> The alternative would be to reconfigure rkhunter.

You could make a start by purging it from your system. It performs no
useful function.

-- 
Brian.

Problemas con pentaho y tomcat

[Romero, Fernando]

Hola como están, tengo un problema con tomcat.
Instale pentaho y me instalo tomcat, pero no puedo levantar la web de pentaho, 
me da error "Estado HTTP 404 - "
Estuve buscando en la web de pentaho pero nada de lo da como solución ahí me 
funciono, alguien tuvo el mismo problema?

Gracias y saludos

Re: sourceforge ou autre

[Sébastien Dinot]

Bonjour,

David Martin a écrit :
> Je me souviens d'avoir utilisé tucows / freshmeat / sourceforge pour
> trouver des petits projets opensource.
>
> tucows et freshmeat n'existant plus, en connaissez vous d'autre à part
> sourceforge ?

Le site « fresh(code) » a pris le relais de FreshMeat quelques années :

http://freshcode.club/ 

Quand j'ai un peu de temps à tuer, j'aimae bien le consulter et j'y
découvre plein de petits projets.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: problème de tri avec sort

[Marc Chantreux]

salut Samy,

je serais heureux de lire si qq1 trouve la solution. toutefois je dois
avouer que pour ma part, j'ai contourné le pb lorsque sort m'a joué ce
genre de tours:

perl -F@ -lane '
push @lines, [@F];
END { map  { print join q(@), @$_ }
  sort { $$a[0] cmp $$b[0] }
  @lines }' <<\.
"a z"@t
"a b"@t
"a"@t
"ac"@t
.

me donne bien

"a b"@t
"a z"@t
"a"@t
"ac"@t

cordialement,
marc

Re: Public Key

[Mario Castelán Castro]

On 24/08/17 10:21, Dan Norton wrote:
> Oops - forgot to try GNU Stow. Another time maybe.

In this case, you used the package manager, so there is no need for
stow. GNU Stow is useful when installing manually, for example, when one
compiles from source.

> Thank you, Mario, for your help. Great discussion.

No problem Dan. Glad to be of help.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan



signature.asc
Description: OpenPGP digital signature

Re: Re : Re : Re : problème de tri avec sort

[Étienne Mollier]

Bonsoir,

On 08/24/2017 07:50 PM, nicolas.patr...@gmail.com wrote:
> Le 24/08/2017 17:57:43, Samy Mezani a écrit :
> 
>> Je viens d'essayer de trier le fichier 2 en ôtant au préalable les 
>> guillemets, voici ce que ça donne :
>> 97  32  98  64 116  10
>> 97  99  64 116  10
>> 97  64 116  10
>> 97  32 122  64 116  10
> 
>> Ça n'a pas l'air d'être dans un ordre lexicographique. C'est ça que je
>> ne comprend pas. Pour le fichier 1 pas de souci, mais pour le 2, à 
>> partir du moment où il y a une 2ème colonne, ça foire…
> 
> Tu devrais lire le manuel de sort pour y voir clair.
> Visiblement, il ne se contente pas de tri lexicographique brut mais plutôt 
> sur les mots.
> 

Exact, au risque de donner la réponse bien vite, j'aimerais
insister sur le gros *warning* à la fin de la page de manuel :

   *** WARNING *** The locale specified by the  environment
   affects sort order.  Set LC_ALL=C to get the traditional
   sort order that uses native byte values.

(mille excuses pour la version du manuel dans la langue de
Shakespeare, je n'ai pas installé les locales Françaises.)

Le réglage de la variable d'environnement LC_ALL a la valeur C
permet de retrouver un comportement « cohérent » à la commande
`sort` :

$ export LC_ALL=C

$ sort fichier1
"a b"
"a z"
"a"
"ac"

$ sort fichier2
"a b"@t
"a z"@t
"a"@t
"ac"@t

$ sort -t@ -k1 fichier2
"a b"@t
"a z"@t
"a"@t
"ac"@t

Notez que dans cet ordre les majuscules arrivent avant les
minuscules, donc si vos commandes `ls` ne réagissent pas comme
d'habitude dans cet environnement, c'est normal :

$ touch IMPORTANT impeumoinportant
$ ls
IMPORTANT  fichier1  fichier2  impeumoinportant
$ LC_ALL=en_US.UTF-8 ls
fichier1  fichier2  impeumoinportant  IMPORTANT

Les problèmes de localisation sont sources de bugs souvent
incompréhensibles et récurrents.  C'est triste, c'est tellement
plus pratique d'avoir une machine qui parle comme soi-même.  :<

À plus,
-- 
Étienne Mollier 

Re: Limitação do comando 'date' ?

[Linux - Junior Polegato]

Olá!

Não é um bug, pois o "date" converte para a data local no 
timezone do sistema quanto não especificado um, e a hora é "00:00:00" 
quando não especificado também.


Como não existiu essa data e horário no seu sistema, que creio 
ser tal com o meu timezone (cat /etc/timezone => America/Sao_Paulo), 
informa que data é inválida, pois realmente é, visto que "2010/10/17 
00:00:00 -02" a "2010/10/17 00:59:59 -02" não existiu no nosso timezone.


Assim sendo pode usar a opção "-u" do "date" para resolver, 
pois existiu "2010/10/17 00:00:00 UTC" (UTC = 00).


--

[]'s

Junior Polegato



Em 24-08-2017 15:00, Tiago Pigazao escreveu:
Excelente  justamente o teste que não fiz , que foi especificando a 
hora ! , para o que pretendo ja vai ajudar bastante

de qualquer forma fica o registro do Bug

Obrigado pessoal

Em 24 de agosto de 2017 14:01, Paulino Kenji Sato > escreveu:


Ola,
Parece ser um bug relacionado com o horário de verão.
Mesmo problema com a data 15 de Outubro de 2017, que e o inicio do
horário de verão deste ano.
date (GNU coreutils) 8.13
Acrescentando o fuso horário ou uma hora que não seja 00:mm:ss
retorna a data.



2017-08-24 13:07 GMT-03:00 Tiago Pigazao >:

Bom dia,

Pessoal, ao fazer alguns testes aqui percebi que o comando
date não reconhece algumas datas por ex:

quando passo uma determinada data ele deve me retornar o dia
da semana, o dia , mês.., usando o parâmetro '-d'  , o que
ocorre é que, quando vou testar uma determinada data ele me
retorna como *data* *invalida *, e da erro no comando como se
fosse a sintaxe errada:

data que apresentou o problema: (esse dia realmente existe)

date -d 2010/10/17

ja tentei mudar a string também como:

date -d '17 oct 2010'


se eu colocar um dia anterior ou posterior , ele funciona sem
problemas , me retornando a saída esperada (dia da semana e
etc..):

date -d 2010/10/16
date -d '16 oct 2010'

date -d 2010/10/18
date -d '18 oct 2010'


outras datas que apresentaram o mesmo efeito, por ex:

2000/10/08
2004/11/02
2009/10/18

a questão é isso Seria uma limitação do date ou eu teria que
especificar um parâmetro adicional para a saída esperada ?

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 12:59:46 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 11:40:28AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> > > On 2017-08-24 at 11:43, David Wright wrote:
> > > 
> > > > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > If things ever do reach a point where that is no longer the common case,
> > > it would then become appropriate to propose changing the default to one
> > > suited for that more-complex configuration.
> > > 
> > > But we are not yet there, or indeed anywhere close to there, so that
> > > should not yet be the default.
> > 
> > By that argument, you wait until lots of people have problems before
> > you change the default to accomodate them, instead of thinking ahead.
> > If you want a simpler default, can you not follow the instructions
> > and give yourself one. For people upgrading, Debian ensured that
> > there would not be an unexpected change; the older methods prevail¹.
> 
> This is the biggest systemic problem I have with Debian today.
> 
> You just made an assumption that does not match my reality, and
> you didn't even realize that you made it. 

That's rather patronising.

> I'm in charge of a lot of Debian-running machines. One of the major
> reasons that we chose Debian is because of the promise that we would be
> able to upgrade in place, rather than wiping the old OS and reinstalling.
> 
> As a result, we buy machines when we need them, not necessarily all at
> once. And we expect a new install of Stretch to behave the same way as
> an upgraded Wheezy-to-Jessie-to-Stretch. 
> 
> It does not.
> 
> That makes Debian worth less than it used to be.

Are you saying that you can get a Wheezy-to-Jessie-to-Stretch machine
to be identical to a new Stretch one without any configuration
adjustments? All you have to do is remove the constraints on the
upgraded machines to make them behave like the new ones. The place
to look is /etc/udev/rules.d/70-persistent-net.rules AIUI.

Cheers,
David.

Re: Limitação do comando 'date' ?

[Tiago Pigazao]

Excelente  justamente o teste que não fiz , que foi especificando a hora !
, para o que pretendo ja vai ajudar bastante
de qualquer forma fica o registro do Bug

Obrigado pessoal

Em 24 de agosto de 2017 14:01, Paulino Kenji Sato 
escreveu:

> Ola,
> Parece ser um bug relacionado com o horário de verão.
> Mesmo problema com a data 15 de Outubro de 2017, que e o inicio do horário
> de verão deste ano.
> date (GNU coreutils) 8.13
> Acrescentando o fuso horário ou uma hora que não seja 00:mm:ss retorna a
> data.
>
>
>
> 2017-08-24 13:07 GMT-03:00 Tiago Pigazao :
>
>> Bom dia,
>>
>> Pessoal, ao fazer alguns testes aqui percebi que o comando date não
>> reconhece algumas datas por ex:
>>
>> quando passo uma determinada data ele deve me retornar o dia da semana, o
>> dia , mês.., usando o parâmetro '-d'  , o que ocorre é que, quando vou
>> testar uma determinada data ele me retorna como *data* *invalida *, e da
>> erro no comando como se fosse a sintaxe errada:
>>
>> data que apresentou o problema: (esse dia realmente existe)
>>
>> date -d 2010/10/17
>>
>> ja tentei mudar a string também como:
>>
>> date -d '17 oct 2010'
>>
>>
>> se eu colocar um dia anterior ou posterior , ele funciona sem problemas ,
>> me retornando a saída esperada (dia da semana e etc..):
>>
>> date -d 2010/10/16
>> date -d '16 oct 2010'
>>
>> date -d 2010/10/18
>> date -d '18 oct 2010'
>>
>>
>> outras datas que apresentaram o mesmo efeito, por ex:
>>
>> 2000/10/08
>> 2004/11/02
>> 2009/10/18
>>
>> a questão é isso Seria uma limitação do date ou eu teria que especificar
>> um parâmetro adicional para a saída esperada ?
>>
>>
>>
>>
>>
>
>
> --
> Paulino Kenji Sato
>

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 13:35:17 (-0400), Greg Wooledge wrote:
> On Thu, Aug 24, 2017 at 11:51:48AM -0500, David Wright wrote:
> > For you, they wrote the last screenful of
> > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> One of the bullet points on that page says:
> 
>  * Stable interface names even if you have to replace broken ethernet
>cards by new ones
> 
> But this is clearly an error, unless they meant "replace with a new
> one of exactly the same type as the old one", which is absolutely not a
> common practice.  You may not even be able to *find* another instance of
> the old one, because the manufacturer has silently changed the internal
> chipset whithout changing the model number on the box.  So you end up
> replacing your interface with a different kind, and voila!  Your
> interface name changes.

When I read that line, I assumed that replacing a NIC in the same slot
would give rise to the same enpXsY numbers which would satisfy the
user alluded to earlier when I wrote 'You can find threads here
complaining loud and long about udev's persistent-net rules, one of
the preceding methods "foisted" on us by Debian.' With the latter, the
NICs new MAC would result in a new entry in persistent-net and a name
change to eth(N+1):.

I don't think I have the hardware to try this out; my only loose NICs
are identical twins.

Cheers,
David.

Re : Re : Re : problème de tri avec sort

[nicolas . patrois]

Le 24/08/2017 17:57:43, Samy Mezani a écrit :

> Je viens d'essayer de trier le fichier 2 en ôtant au préalable les 
> guillemets, voici ce que ça donne :
> 97  32  98  64 116  10
> 97  99  64 116  10
> 97  64 116  10
> 97  32 122  64 116  10

> Ça n'a pas l'air d'être dans un ordre lexicographique. C'est ça que je
> ne comprend pas. Pour le fichier 1 pas de souci, mais pour le 2, à 
> partir du moment où il y a une 2ème colonne, ça foire…

Tu devrais lire le manuel de sort pour y voir clair.
Visiblement, il ne se contente pas de tri lexicographique brut mais plutôt sur 
les mots.

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...

Re: One-line password generator

[Brian]

On Wed 23 Aug 2017 at 18:06:49 -0500, Mario Castelán Castro wrote:

> On 23/08/17 14:11, Brian wrote:
> >> As for the scenario where the password is compromised and that leads to
> >> somebody posting slander in one behalf, that can happen without any need
> >> for password cracking. Anybody can create a profile in a social network
> >> pretending to be you with the intention to taint your reputation.
> >>
> >> Hence that only your reputation as perceived by stupid people would
> >> suffer from such an attack.
> > 
> > A slander coming from your own (compromised) account is somewhat
> > different from one posted from a created account. It is a lot harder
> > to deny one but not the other.
> 
> The problem here is that only *you* know which account is legitimate and
> which is the impersonator. The rest of people read that account A claims
> that account B is impersonating it, but they can not know that is true,
> or whether it is actually the other way, or whether account B is
> actually the same person as account A but posing as a impersonator of
> himself (like the so called “self-robbery”).
> 
> If you have access to an account, you can prove this easily to anybody
> through a challenge-response protocol. However, in general you can not
> prove that you do *NOT* have access to an account. It can be done only
> in *some cases*. For example, if you were unconscious in the hospital,
> the hospital personnel can attest to this. Of course, this works only if
> people is willing to trust the hospital personnel.

It comes down (IME) to protecting and preserving one's online identity.
Treating some accounts as deserving passw0rd while others get a urandom
generated Odju56LAVGMXl8nJQBE4KA is not conducive to that. Also, taking
shortcuts in health and safety matters rarely turn out well.
 
> >>> "Probably" is probably good enough. The probability of either of the two
> >>> previous passwords being deduced from pure guessing is close to zero.
> >>
> >> It is not human guessing, but brute force attacks with specialized
> >> hardware what you should try to protect against.
> > 
> > It is all "human guessing". Think about it. Machines do not guess by
> > themselves. Not yet anyway!
> > 
> > Two passwords:
> > 
> >   IhaveaMemorablePasswordwhichIwillnotforget!
> > 
> >   MyDogHasNoNose.HowDoesItSmell?Terrible!
> > 
> > Please would you give your opinion of how long it would take to brute
> > force these over the network.
> > 
> > (I do not understand "specialized hardware" when it is network attacks.)
> 
> An answer can not be given for “how long it would take” because this
> question depends on too many factors. It is an open-ended question.

Fair enough.
 
> Anyway, you have to take into account that sometimes a data base of
> hashed passwords of the users can be  obtained through normal cracking.
> Then the attacker can perform a brute force search without any further
> need for network access.
> 
> If your ~/.gnupg directory leaks, then your OpenPGP key is protected
> only by your password. No network access is required after the initial leak.

I'll give you that. 50,000 tests per second offline (or whatever it is
now) beats an online attack of a few hundred (?) per second any day of
the week.

I've seen it said that a memorable password is a weak password. Perhaps
there is some truth in that, but (again IME) it needn't be so.

-- 
Brian.

Re: Question to new network device names

[Greg Wooledge]

On Thu, Aug 24, 2017 at 11:51:48AM -0500, David Wright wrote:
> For you, they wrote the last screenful of
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

One of the bullet points on that page says:

 * Stable interface names even if you have to replace broken ethernet
   cards by new ones

But this is clearly an error, unless they meant "replace with a new
one of exactly the same type as the old one", which is absolutely not a
common practice.  You may not even be able to *find* another instance of
the old one, because the manufacturer has silently changed the internal
chipset whithout changing the model number on the box.  So you end up
replacing your interface with a different kind, and voila!  Your
interface name changes.

Of course debian-user is not the place to get errors on the freedesktop
page corrected, but the author of that page is clearly not playing by
the same rules as the rest of us.

Re: Limitação do comando 'date' ?

[Paulino Kenji Sato]

Ola,
Parece ser um bug relacionado com o horário de verão.
Mesmo problema com a data 15 de Outubro de 2017, que e o inicio do horário
de verão deste ano.
date (GNU coreutils) 8.13
Acrescentando o fuso horário ou uma hora que não seja 00:mm:ss retorna a
data.



2017-08-24 13:07 GMT-03:00 Tiago Pigazao :

> Bom dia,
>
> Pessoal, ao fazer alguns testes aqui percebi que o comando date não
> reconhece algumas datas por ex:
>
> quando passo uma determinada data ele deve me retornar o dia da semana, o
> dia , mês.., usando o parâmetro '-d'  , o que ocorre é que, quando vou
> testar uma determinada data ele me retorna como *data* *invalida *, e da
> erro no comando como se fosse a sintaxe errada:
>
> data que apresentou o problema: (esse dia realmente existe)
>
> date -d 2010/10/17
>
> ja tentei mudar a string também como:
>
> date -d '17 oct 2010'
>
>
> se eu colocar um dia anterior ou posterior , ele funciona sem problemas ,
> me retornando a saída esperada (dia da semana e etc..):
>
> date -d 2010/10/16
> date -d '16 oct 2010'
>
> date -d 2010/10/18
> date -d '18 oct 2010'
>
>
> outras datas que apresentaram o mesmo efeito, por ex:
>
> 2000/10/08
> 2004/11/02
> 2009/10/18
>
> a questão é isso Seria uma limitação do date ou eu teria que especificar
> um parâmetro adicional para a saída esperada ?
>
>
>
>
>


-- 
Paulino Kenji Sato

Re: Question to new network device names

[Dan Ritter]

On Thu, Aug 24, 2017 at 11:40:28AM -0500, David Wright wrote:
> On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> > On 2017-08-24 at 11:43, David Wright wrote:
> > 
> > > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > If things ever do reach a point where that is no longer the common case,
> > it would then become appropriate to propose changing the default to one
> > suited for that more-complex configuration.
> > 
> > But we are not yet there, or indeed anywhere close to there, so that
> > should not yet be the default.
> 
> By that argument, you wait until lots of people have problems before
> you change the default to accomodate them, instead of thinking ahead.
> If you want a simpler default, can you not follow the instructions
> and give yourself one. For people upgrading, Debian ensured that
> there would not be an unexpected change; the older methods prevail¹.

This is the biggest systemic problem I have with Debian today.

You just made an assumption that does not match my reality, and
you didn't even realize that you made it. 

I'm in charge of a lot of Debian-running machines. One of the major
reasons that we chose Debian is because of the promise that we would be
able to upgrade in place, rather than wiping the old OS and reinstalling.

As a result, we buy machines when we need them, not necessarily all at
once. And we expect a new install of Stretch to behave the same way as
an upgraded Wheezy-to-Jessie-to-Stretch. 

It does not.

That makes Debian worth less than it used to be.

-dsr-

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 11:56:55 (-0400), The Wanderer wrote:

> At my workplace, we have over 4,000 computers, which run Windows most of
> the time but are occasionally booted to a bare-bones live-CD type of
> Linux environment (and not a particularly customizable one) for
> diagnostic and/or maintenance work.
> 
> We've had enough trouble with the fact that some of them come up with
> the interface name /dev/em1 (which I think is supplied directly by the
> kernel) rather than /dev/eth0; having the full multiplicity of names
> available under the "predictable network interface names" scheme to sort
> through, rather than at least being limited to only two, would be enough
> more of a pain that I don't want to consider it.

For you, they wrote the last screenful of
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Cheers,
David.

Re: Help setting up Broadcom WiFi on a Dell Inspiron 1501 laptop

[rhkramer]

Thanks, that is a very helpful page.  I send a response to your earlier email 
to the list, and I'm going to do the same with this.

On Thursday, August 24, 2017 12:12:47 PM Wim Michels wrote:
> Hi,
> 
> have a look at this webpage:
> 
> https://wiki.debian.org/WiFi/HowToUse
> 
> for usefull info.
> 
> On Wednesday, 23 August at 21:40, rhkra...@gmail.com wrote:
> >On Sunday, August 20, 2017 03:00:28 PM Wim Michels wrote:
> >> Hi,
> >> all you need to install is the package:
> >> 
> >> firmware-b43-installer
> >> 
> >> from 'contrib' to get BCM4311 chip to work.
> >
> >Thanks, that worked!

Re: Help setting up Broadcom WiFi on a Dell Inspiron 1501 laptop

[rhkramer]

On Wednesday, August 23, 2017 03:40:07 PM rhkra...@gmail.com wrote:
> On Sunday, August 20, 2017 03:00:28 PM Wim Michels wrote:
> > Hi,
> > all you need to install is the package:
> > 
> > firmware-b43-installer
> > 
> > from 'contrib' to get BCM4311 chip to work.
> 
> Thanks, that worked!

Just wanted to add one thing--that worked for me in Wheezy, but not in Jessie.  
It's possible that I did something wrong while in Jessie (I might have typed 
nonfree instead of non-free in /etc/apt/sources.list).  I haven't tried to 
reinstall Jessie to retry--I plan to live with Wheezy (unless I get very 
ambitious in the near future.

Oh, and I meant to send / keep this on the list, so sending to the list.

> 
> I do need to learn more about how wireless networking and/or Network
> Manager work, but I did get connected.
> 
> I did have to reboot after doing the install (as it didn't work before I
> rebooted, using about the same things that did work after the reboot).  I
> suppose if I knew more I might have avoided the reboot, maybe by stopping
> and restarting some network related service.  (But, this was a new
> install, and rebooting did not cause any problems.)
> 
> Thanks again!
> 
> Aside: There were, iirc, three other methods I was thinking of trying to
> get it to work (all basically headed in the same direction)--I have some
> notes about those in my off-line wiki-like thing and may try experimenting
> with those sometime (but, probably not ;-)

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> On 2017-08-24 at 11:43, David Wright wrote:
> 
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> 
> >> Getting back to the original point, NIC names -- virtually every
> >> computer has exactly one or two NICs, and is best served by eth0
> >> and wlan0. The computers with 3-5 NICs are usually best served that
> >> way. More complex naming schemes are helpful when you have a router
> >> or switch, and it's nice that Debian supports that, but hardly a
> >> good default.
> > 
> > There are plenty of ways that you, or Debian, can set a default. But
> > it surprises me that so many people grumble about this change. The
> > history of computing is littered with statements like "virtually
> > every computer has exactly one or two NICs".
> 
> The thing is, currently that statement[1] *is* correct, so *currently*
> the default should be suited for that configuration.
> 
> If things ever do reach a point where that is no longer the common case,
> it would then become appropriate to propose changing the default to one
> suited for that more-complex configuration.
> 
> But we are not yet there, or indeed anywhere close to there, so that
> should not yet be the default.

By that argument, you wait until lots of people have problems before
you change the default to accomodate them, instead of thinking ahead.
If you want a simpler default, can you not follow the instructions
and give yourself one. For people upgrading, Debian ensured that
there would not be an unexpected change; the older methods prevail¹.

> > This list is full of postings about the complex DNS system. But how
> > long did /etc/hosts last?
> 
> It's still there and still in use, albeit not as a primary source, last
> I checked...

It's the *only* source here for such as 192.168.1.13wasp
but I was assuming you'd understand I was talking about non-local
hosts on the Internet.

> [1] Actually, the more precise statement involving "at most one NIC of
> each type, wired and wireless" would be more accurate, because a machine
> with two NICs of the same type would still benefit from the "predictable
> network interface names" scheme.

Yes, and I remember the problems I had when all my NICs were
3c509s from the free shop (Academic Computing Services) and
I put two in the same box. These (problems) would be unacceptable
nowadays.

You can't please everyone. You can find threads here complaining
loud and long about udev's persistent-net rules¹, one of the
preceding methods "foisted" on us by Debian.

Cheers,
David.

Re: Limitação do comando 'date' ?

[Sérgio Abrantes Junior]

Tiago,

É bug!

Testei numa imagem de Slackware que tenho aqui e das datas que você
informou, não apresentaram problemas.
No Debian da mesmo erro.
Relate o bug para os desenvolvedores.

Até!

Sérgio Abrantes

Em 24 de agosto de 2017 13:07, Tiago Pigazao  escreveu:

> Bom dia,
>
> Pessoal, ao fazer alguns testes aqui percebi que o comando date não
> reconhece algumas datas por ex:
>
> quando passo uma determinada data ele deve me retornar o dia da semana, o
> dia , mês.., usando o parâmetro '-d'  , o que ocorre é que, quando vou
> testar uma determinada data ele me retorna como *data* *invalida *, e da
> erro no comando como se fosse a sintaxe errada:
>
> data que apresentou o problema: (esse dia realmente existe)
>
> date -d 2010/10/17
>
> ja tentei mudar a string também como:
>
> date -d '17 oct 2010'
>
>
> se eu colocar um dia anterior ou posterior , ele funciona sem problemas ,
> me retornando a saída esperada (dia da semana e etc..):
>
> date -d 2010/10/16
> date -d '16 oct 2010'
>
> date -d 2010/10/18
> date -d '18 oct 2010'
>
>
> outras datas que apresentaram o mesmo efeito, por ex:
>
> 2000/10/08
> 2004/11/02
> 2009/10/18
>
> a questão é isso Seria uma limitação do date ou eu teria que especificar
> um parâmetro adicional para a saída esperada ?
>
>
>
>
>

Re: Question to new network device names

[Dan Ritter]

On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > There are, of course, five different ways to do this (at a
> > minimum):
> > 
> > 1. /dev/sda1 is based on discovery order. Changes in discovery order
> > may indicate a significant problem that you need to investigate -- or not.
> 
> I'm having difficulty imagining a scenario where the identity
> of sdaX, in particular, is unimportant (for most people).

Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and 
have /dev/sda, b, c and d in an mdadm RAID10. 

mdadm will scan all disks looking for its signature, and will
assemble them into /dev/md/0 regardless of physical disk
location. So it really won't matter to you whether you have the
same disks in /dev/sdX from boot to boot as long as they are
all there.

But for most people, most of the time, swapping /dev/sda and
/dev/sdc would be a problem.

> But in connection with the original NIC discussion, the absence
> of disk/by-uuid would be sorely missed if it weren't there, which
> is why some improvement on eth0, eth1 assignment was needed,
> and the result was a very flexible system IMO.
> 
> > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> > have their own ideas about what to do and how to do it, which may include
> > any of the above methods as well as their own peculiarities.
> > 
> > That said, if you have a laptop or a desktop with 1-2 disks, you
> > are probably going to be perfectly happy with either /dev/sda1 or
> > LABEL=root-$HOSTNAME addressing.
> 
> With two disks on a BIOS computer, you have an immediate problem,
> don't you? That what disk-swapping was all about. And that was when
> everything was on ATA.

On a well-working computer, device discovery order is constant without
physical changes. sda will always be sda, until it breaks or
something else (bad) happens.

> But now look at the debates here on, for example, how an SD card
> is going to appear to the system. The schematic diagram of any laptop
> looks like a forest of USBs (and other types) so which is going to win
> the race to become sda?

They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or BIOS
will become sda. Or if you've got an internal USB port with a
stick in it, that might be a selected candidate. In no case
should it change without hardware failure or physical
rearrangement.

The question is, how will your newly plugged in SD card become
sdk rather than sdj, and the answer is that mass storage devices
that are expected to be rearranged should be treated differently 
from those which are expected to always be available from
boot-time onwards.


> > Getting back to the original point, NIC names -- virtually every computer
> > has exactly one or two NICs, and is best served by eth0 and wlan0. The
> > computers with 3-5 NICs are usually best served that way. More complex
> > naming schemes are helpful when you have a router or switch, and it's
> > nice that Debian supports that, but hardly a good default.
> 
> There are plenty of ways that you, or Debian, can set a default.
> But it surprises me that so many people grumble about this change.

People grumble about changes for several nonexclusive reasons:

1. The change broke what they were doing.
2. The change broke their mental model of what they were doing.
3. The change did not bring them perceived benefits.
4. The change appears arbitrary.
5. The change fixed a problem but they perceive better ways to
   solve the problem.
6. The change creates new problems.


> The history of computing is littered with statements like
> "virtually every computer has exactly one or two NICs".

It used to be zero.

We are currently in the phase of history where this statement is
true. NICs are both ubiquitous and cheap, yet devices tend to
come with one (only an ethernet port or only a wifi radio) or
two (one of each of those, or a wifi radio and a cell radio).

Devices can add more, but they are always special cases: my 
Debian-running firewall has 5 ethernet ports. I occasionally
add a USB ethernet frob in order to isolate a device that I want
to talk to directly. Special cases deserve special treatment.

I expect the statement to remain true for the next ten years.

Do you expect differently? If so, why?


> This list is full of postings about the complex DNS system. But
> how long did /etc/hosts last? Some complexity is unavoidable,
> but if you try to avoid it, you pay for it later. Look at timezones.
> Ever allowing computers' internal clocks to run on local time
> was, with hindsight, a big mistake. Leap seconds might also
> be seen the same way (still under debate).

/etc/hosts still acts the way it always did -- put in an entry,
it overrides DNS.

Timezones are a human legal-social problem, and the ability of
technology to deal with those is known to be problematic.

-dsr-

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 09:17:00 (-0400), The Wanderer wrote:
> On 2017-08-24 at 07:52, to...@tuxteam.de wrote:
> 
> > On Thu, Aug 24, 2017 at 01:11:27PM +0200, Hans wrote:
> >
> >> Hi folks,
> > 
> >> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and 
> >> of 
> >> course I know, that this is obviously the newe standard (please correct 
> >> me, i 
> >> I am wrong).
> 
> >> So, what is the status today? How have people accepted the new names also 
> >> for 
> >> long running systems? 
> > 
> > I'd say: if you have a box with a huge number of interfaces, or if your
> > interface's hardware is brought up dynamically (picture a bunch of USB
> > hubs with 16 eth interface adapters at its tips, to have something your
> > phantasy can attach to), where the loading order of the corresponding
> > kernel modules determine who is first and who is last, whoever is eth0
> > and whoever is eth15 may change from boot to boot.
> > 
> > You don't want that, especially when those are attached to different
> > networks (picture a firewall/router...)
> > 
> > A similar case is when the interfaces come and go (e.g. plugging in and
> > out said USB adapters. All this doesn't need to be USB -- in the more
> > expensive world you can plug in (and out!) RAM and CPUs, while the
> > system is running).
> > 
> > Predictable names (try to) bring up the "same" interface with the "same"
> > name each time (although "same" itself isn't well-defined; IMHO this
> > makes a 100% job impossible anyway).
> 
> However, I'll point out that machines with this many network interfaces
> are *by far* the exception rather than the rule; indeed, even machines
> with more than *one* interface each of wired and wireless are reasonably
> rare. As such, the scenario in which this naming scheme makes interface
> names more predictable is not one which most people will ever encounter.
> (...which calls into question the appropriateness of making this scheme
> the default.)
> 
> To the best of my awareness, the rationale for calling this "predictable
> network interface names" is that, on a single computer which has
> multiple network interfaces of a given type, this naming scheme makes
> it possible to predict *from one boot to the next* what the name of each
> one will be. On such a computer, this is extremely valuable.
> 
> By contrast, on a computer which has at most one interface of a given
> type, this naming scheme provides - so far as I can tell - no advantage
> at all.
> 
> What's more, when working on *multiple* computers of that latter type,
> this naming scheme makes it impossible to predict *from one computer to
> the next* what the name of the sole available interface will be.
> 
> As such, IMO this naming scheme makes network-interface names
> significantly *less* predictable in the real-world scenario which is
> most commonly encountered.
> 
> On that basis and from that perspective, the choice of "predictable
> network interface names" as the label for this naming scheme seems
> downright Orwellian.

Running wheezy and jessie, the lspci output from this laptop included
the lines

 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 Gigabit 
Ethernet (rev 03)
 02:04.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] 
Network Connection (rev 05)

so it was "predictable¹" that installing stretch would yield these:

 kernel: [  111.443209] tg3 :02:02.0 enp2s2: renamed from eth0

 kernel: [  134.994910] ipw2200 :02:04.0 wlp2s4: renamed from eth0

in its syslog. In case the eth0 duplication perplexes you, the
wireless card in squeeze, wheezy and jessie is called eth1. Don't ask
me why. That *was* unpredictable AFAICT.

¹Predictability is based on the output of lspci, according to the
page referenced earlier.

Cheers,
David.

Limitação do comando 'date' ?

[Tiago Pigazao]

Bom dia,

Pessoal, ao fazer alguns testes aqui percebi que o comando date não
reconhece algumas datas por ex:

quando passo uma determinada data ele deve me retornar o dia da semana, o
dia , mês.., usando o parâmetro '-d'  , o que ocorre é que, quando vou
testar uma determinada data ele me retorna como *data* *invalida *, e da
erro no comando como se fosse a sintaxe errada:

data que apresentou o problema: (esse dia realmente existe)

date -d 2010/10/17

ja tentei mudar a string também como:

date -d '17 oct 2010'


se eu colocar um dia anterior ou posterior , ele funciona sem problemas ,
me retornando a saída esperada (dia da semana e etc..):

date -d 2010/10/16
date -d '16 oct 2010'

date -d 2010/10/18
date -d '18 oct 2010'


outras datas que apresentaram o mesmo efeito, por ex:

2000/10/08
2004/11/02
2009/10/18

a questão é isso Seria uma limitação do date ou eu teria que especificar um
parâmetro adicional para a saída esperada ?

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 11:43, David Wright wrote:

> On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:

>> Getting back to the original point, NIC names -- virtually every
>> computer has exactly one or two NICs, and is best served by eth0
>> and wlan0. The computers with 3-5 NICs are usually best served that
>> way. More complex naming schemes are helpful when you have a router
>> or switch, and it's nice that Debian supports that, but hardly a
>> good default.
> 
> There are plenty of ways that you, or Debian, can set a default. But
> it surprises me that so many people grumble about this change. The
> history of computing is littered with statements like "virtually
> every computer has exactly one or two NICs".

The thing is, currently that statement[1] *is* correct, so *currently*
the default should be suited for that configuration.

If things ever do reach a point where that is no longer the common case,
it would then become appropriate to propose changing the default to one
suited for that more-complex configuration.

But we are not yet there, or indeed anywhere close to there, so that
should not yet be the default.

> This list is full of postings about the complex DNS system. But how
> long did /etc/hosts last?

It's still there and still in use, albeit not as a primary source, last
I checked...


[1] Actually, the more precise statement involving "at most one NIC of
each type, wired and wireless" would be more accurate, because a machine
with two NICs of the same type would still benefit from the "predictable
network interface names" scheme.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Re : Re : problème de tri avec sort

[Samy Mezani]

Le 24/08/2017 à 17:19, nicolas.patr...@gmail.com a écrit :

sort trie les lignes selon l’ordre lexicographique de la table ASCII.
Regarde les codes ASCII de chaque caractère de chaque ligne.
Le premier :
34-97-34-10
34-97-32-98-34-10
34-97-99-34-10
34-97-32-122-34-10
Le deuxième :
34-97-32-122-34-64-116-10
34-97-32-98-34-64-116-10
34-97-34-64-116-10
34-97-99-34-64-116-10


Je viens d'essayer de trier le fichier 2 en ôtant au préalable les 
guillemets, voici ce que ça donne :

97  32  98  64 116  10
97  99  64 116  10
97  64 116  10
97  32 122  64 116  10

Ça n'a pas l'air d'être dans un ordre lexicographique. C'est ça que je 
ne comprend pas. Pour le fichier 1 pas de souci, mais pour le 2, à 
partir du moment où il y a une 2ème colonne, ça foire…


D'autres pistes ?

Merci

Samy

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 11:48, Darac Marjal wrote:

> On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:
> 
>> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:

>>> To the best of my awareness, the rationale for calling this
>>> "predictable network interface names" is that, on a single
>>> computer which has multiple network interfaces of a given type,
>>> this naming scheme makes it possible to predict *from one boot to
>>> the next* what the name of each one will be. On such a computer,
>>> this is extremely valuable.
>>> 
>>> By contrast, on a computer which has at most one interface of a
>>> given type, this naming scheme provides - so far as I can tell -
>>> no advantage at all.
>>> 
>>> What's more, when working on *multiple* computers of that latter
>>> type, this naming scheme makes it impossible to predict *from one
>>> computer to the next* what the name of the sole available
>>> interface will be.
>>> 
>>> As such, IMO this naming scheme makes network-interface names 
>>> significantly *less* predictable in the real-world scenario which
>>> is most commonly encountered.
>> 
>> This closely parallels the move from using /dev/sdXn to UUIDs for 
>> referring to filesystems.  Probably superior in theory and doesn't
>> cause any issues as long as you're dealing with a single machine
>> and unchanging hardware configuration... but then you have a drive
>> failure, restore your backups onto new hardware, and you're hosed
>> because the system wants to boot from a UUID that no longer exists.
>> (Yes, you can recover from that situation - I know because I've had
>> to do it - but it doesn't Just Work(TM) effortlessly.)
> 
> I think you're right here and, in both cases, if you're not using
> more manageable names, then you're not using the system to its
> fullest.
> 
> You wouldn't refer to a host by it's IP address, or it's MAC address
> or it's Serial Number, you'd give it a name. So why not name your
> drives (and then use the by-label or LABEL= system) and why not name
> your interfaces (core-network0, core-network1, backup-lan,
> monitoring-lan - they don't HAVE to have numbers)

While that's not a bad idea... how does it help the case of "network
names are not predictable from one computer to the next"?

At my workplace, we have over 4,000 computers, which run Windows most of
the time but are occasionally booted to a bare-bones live-CD type of
Linux environment (and not a particularly customizable one) for
diagnostic and/or maintenance work.

We've had enough trouble with the fact that some of them come up with
the interface name /dev/em1 (which I think is supplied directly by the
kernel) rather than /dev/eth0; having the full multiplicity of names
available under the "predictable network interface names" scheme to sort
through, rather than at least being limited to only two, would be enough
more of a pain that I don't want to consider it.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Question to new network device names

[Darac Marjal]

On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:

On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:

However, I'll point out that machines with this many network interfaces
are *by far* the exception rather than the rule; indeed, even machines
with more than *one* interface each of wired and wireless are reasonably
rare.


In the home desktop space, perhaps.  When you deal with rackmount
servers, OTOH, four (wired) network ports is pretty standard these days.

Of course, they're all on the same bus and using identical hardware/
firmware, so the "order might change based on which drivers load first"
case still doesn't apply.


To the best of my awareness, the rationale for calling this "predictable
network interface names" is that, on a single computer which has
multiple network interfaces of a given type, this naming scheme makes
it possible to predict *from one boot to the next* what the name of each
one will be. On such a computer, this is extremely valuable.

By contrast, on a computer which has at most one interface of a given
type, this naming scheme provides - so far as I can tell - no advantage
at all.

What's more, when working on *multiple* computers of that latter type,
this naming scheme makes it impossible to predict *from one computer to
the next* what the name of the sole available interface will be.

As such, IMO this naming scheme makes network-interface names
significantly *less* predictable in the real-world scenario which is
most commonly encountered.


This closely parallels the move from using /dev/sdXn to UUIDs for
referring to filesystems.  Probably superior in theory and doesn't cause
any issues as long as you're dealing with a single machine and
unchanging hardware configuration... but then you have a drive failure,
restore your backups onto new hardware, and you're hosed because the
system wants to boot from a UUID that no longer exists.  (Yes, you can
recover from that situation - I know because I've had to do it - but it
doesn't Just Work(TM) effortlessly.)


I think you're right here and, in both cases, if you're not using more 
manageable names, then you're not using the system to its fullest.


You wouldn't refer to a host by it's IP address, or it's MAC address or 
it's Serial Number, you'd give it a name. So why not name your drives 
(and then use the by-label or LABEL= system) and why not name your 
interfaces (core-network0, core-network1, backup-lan, monitoring-lan - 
they don't HAVE to have numbers)



--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:

> > This closely parallels the move from using /dev/sdXn to UUIDs for
> > referring to filesystems.  Probably superior in theory and doesn't cause
> > any issues as long as you're dealing with a single machine and
> > unchanging hardware configuration... but then you have a drive failure,
> > restore your backups onto new hardware, and you're hosed because the
> > system wants to boot from a UUID that no longer exists.  (Yes, you can
> > recover from that situation - I know because I've had to do it - but it
> > doesn't Just Work(TM) effortlessly.)
> 
> There are, of course, five different ways to do this (at a
> minimum):
> 
> 1. /dev/sda1 is based on discovery order. Changes in discovery order
> may indicate a significant problem that you need to investigate -- or not.

I'm having difficulty imagining a scenario where the identity
of sdaX, in particular, is unimportant (for most people).

> 2. /dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S251NXAH217600A is based
> on drive type and serial number. This is great if you treat changing a
> disk as a serious problem that requires human intervention, and terrible
> if you want a replacement disk to be handled automatically.

I find this useful for identifying bootable Debian USB sticks
whose 'soft' identities vary from one revision/architecture/whatever
to the next. It probably fails for multiple cheap generic USBs
that have no firmware serial number.

> 3. /dev/disk/by-label/sheepdog is based on filesystem labels.  These are
> very good for mounting but useless for identifying specific disks,
> and they can have collision problems.

I find this ideal for most disks. It's amazingly easy to write the
human-friendly LABEL on the device with a marker pen, and I do use
stable partitioning numbering. All my hard drives are labelled thus,
and the USB sticks and SD cards that aren't already identifiable.

But I understand that I'm working within my own defined universe
of devices, and don't expect this to work for all others.
(Now think NICs.)

> 4. /dev/disk/by-path/pci-:00:1f.2-ata-1-part1 is based on disk
> controller topology. If you are interested in what's in a particular
> disk slot rather than the particular disk in it, this is your choice.
> 
> 5. /dev/disk/by-uuid/428366118125845852 identifies filesystems just
> like by-label, and while it is unlikely to have an accidental collision
> problem, does have a deliberate collision problem when you have copies
> of filesystems.

If genuine GUIDs, they're great for machines but no so much for
humans. If they're not genuine, they have to be checked, if it
matters, and that can be tedious.

But in connection with the original NIC discussion, the absence
of disk/by-uuid would be sorely missed if it weren't there, which
is why some improvement on eth0, eth1 assignment was needed,
and the result was a very flexible system IMO.

> 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> have their own ideas about what to do and how to do it, which may include
> any of the above methods as well as their own peculiarities.
> 
> That said, if you have a laptop or a desktop with 1-2 disks, you
> are probably going to be perfectly happy with either /dev/sda1 or
> LABEL=root-$HOSTNAME addressing.

With two disks on a BIOS computer, you have an immediate problem,
don't you? That what disk-swapping was all about. And that was when
everything was on ATA.

But now look at the debates here on, for example, how an SD card
is going to appear to the system. The schematic diagram of any laptop
looks like a forest of USBs (and other types) so which is going to win
the race to become sda?

> Getting back to the original point, NIC names -- virtually every computer
> has exactly one or two NICs, and is best served by eth0 and wlan0. The
> computers with 3-5 NICs are usually best served that way. More complex
> naming schemes are helpful when you have a router or switch, and it's
> nice that Debian supports that, but hardly a good default.

There are plenty of ways that you, or Debian, can set a default.
But it surprises me that so many people grumble about this change.
The history of computing is littered with statements like
"virtually every computer has exactly one or two NICs".
This list is full of postings about the complex DNS system. But
how long did /etc/hosts last? Some complexity is unavoidable,
but if you try to avoid it, you pay for it later. Look at timezones.
Ever allowing computers' internal clocks to run on local time
was, with hindsight, a big mistake. Leap seconds might also
be seen the same way (still under debate).

Cheers,
David.

Re: Script con output de comando

[fernando sainz]

El día 24 de agosto de 2017, 17:12, Josu Lazkano
 escribió:
> Buenas,
>
> Estoy intentando crear un script para poder comprobar el estado de mi TV
> mediante CEC.
>
> Lo que quiero es utilizar la salida de un comando para crear un script. El
> comando es el siguiente:
>
> # echo 'pow 0' | cec-client -s -d 1
>
> Y si la TV esta en marcha muestra:
>
> # echo 'pow 0' | cec-client -s -d 1
> opening a connection to the CEC adapter...
> power status: on
>
> Y si esta apagada muestra:
>
> # echo 'pow 0' | cec-client -s -d 1
> opening a connection to the CEC adapter...
> power status: standby
>
>
> Lo que quiero es hacer algo asi:
>
> if [[ $(echo 'pow 0' | cec-client -s -d 1) == "power status: standby" ]];
> then
>   echo "La TV está apagada"
> else
>   echo "La TV está en marcha"
> fi
>
> Pero no me funciona la condición del IF, ¿como puedo comprar una salida de
> un comando?
>
> Agradezco vuestra ayuda.
>
> Un saludo.
>
>
> --
> Josu Lazkano

Hola.
La sintaxis parece correcta, podría ser algún carácter de nueva linea
en la salida.

Prueba a depurarlo con:  bash -x script.sh
Esto te mostrará las cadenas que se comparan en el if y podrás ver el problema.

S2.

Re: sourceforge ou autre

[bernard . schoenacker]

- Mail original -

> De: "David Martin" 
> À: "debian-user-french@lists.debian.org French"
> 
> Envoyé: Jeudi 24 Août 2017 16:09:20
> Objet: sourceforge ou autre

> Bonjour

> Je me souviens d'avoir utilisé tucows / freshmeat / sourceforge pour
> trouver des
> petits projets opensource.

> tucows et freshmeat n'existant plus, en connaissez vous d'autre à
> part sourceforge ?

> --

> david martin

bonjour, 

il y a alternativeto.net 

slt 
bernard 

Re: Script con output de comando

[Matias Mucciolo]

On Thursday 24 August 2017 17:12:53 Josu Lazkano wrote:
> Buenas,
> 
> Estoy intentando crear un script para poder comprobar el estado de mi TV
> mediante CEC.
> 
> Lo que quiero es utilizar la salida de un comando para crear un script. El
> comando es el siguiente:
> 
> # echo 'pow 0' | cec-client -s -d 1
> 
> Y si la TV esta en marcha muestra:
> 
> # echo 'pow 0' | cec-client -s -d 1
> opening a connection to the CEC adapter...
> power status: on
> 
> Y si esta apagada muestra:
> 
> # echo 'pow 0' | cec-client -s -d 1
> opening a connection to the CEC adapter...
> power status: standby
> 
> 
> Lo que quiero es hacer algo asi:
> 
> if [[ $(echo 'pow 0' | cec-client -s -d 1) == "power status: standby" ]];
> then
>   echo "La TV está apagada"
> else
>   echo "La TV está en marcha"
> fi
> 
> Pero no me funciona la condición del IF, ¿como puedo comprar una salida de
> un comando?
> 
> Agradezco vuestra ayuda.
> 
> Un saludo.
> 
> 
> -- 
> Josu Lazkano



Buenas 


proba con eso 
es una sola linea
podes dividirlo en varias como un if/else comun

if  echo 'pow 0' | cec-client -s -d 1 | grep "status: on"   > /dev/null ; then 
echo prendida  ; else echo apagada ; fi

saludos.

Matias

Re: escritorios sin graficos

[José Mateo Ruiz]

Hola Alexlikerock:
Decías el  Miércoles, 23 de Agosto del 2017.

> 
> Buenas tardes.
> 
> Tengo debia 7 instalado a modo consola, nada de gráficos
> 
> Cómo puedo tener 2 o 3 terminales al mismo tiempo??
> 
> Alguna idea??
> 
> Veo respuestas pero todo en modo gráfico, estoy a como consola sin 
> gráficos.
> 
> Agradezco toda ayuda
> 
> 
> 

Mira esta página, http://www.sromero.org/wiki/linux/aplicaciones/tmux

 

-- 
(·)>
/|\José Tomás Mateo Ruiz
\_/_50550 Aragón España
---
El mejor regalo que podemos darle a otra persona es nuestra atención
íntegra.
-- Richard Moss.

Re : Re : problème de tri avec sort

[nicolas . patrois]

Le 24/08/2017 16:56:53, Samy Mezani a écrit :

> Pourrais-tu détailler, je ne comprend pas trop ta phrase.

sort trie les lignes selon l’ordre lexicographique de la table ASCII.
Regarde les codes ASCII de chaque caractère de chaque ligne.
Le premier :
34-97-34-10
34-97-32-98-34-10
34-97-99-34-10
34-97-32-122-34-10
Le deuxième :
34-97-32-122-34-64-116-10
34-97-32-98-34-64-116-10
34-97-34-64-116-10
34-97-99-34-64-116-10

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...

Re: Public Key

[Dan Norton]

On 08/23/2017 10:07 PM, Mario Castelán Castro wrote:

On 23/08/17 20:52, Dan Norton wrote:


Since borg is a self-contained binary, perhaps it does not need to be
formally declared as a package in Debian 8.

There is no relation between “is self-contained binary” and whether it
is in Debian. Again, borgbackup is available in Debian 8, but you have
to enable backports.

Moreover, Debian package borgbackups is not a self-contained binary. It
uses the package manager to install the dependencies, just as any other
package. It makes more sense this way when it is installed through the
package manager.


OK, following instructions for installing backports (thanks, Greg)



I added the following to /etc/apt/sources.list :
deb http://ftp.debian.org/debian jessie-backports main

followed by...
apt-get update
apt-get -t jessie-backports install borgbackup

and borg is installed.



By the way, I recommend to use GNU Stow
 when installing packages manually.
It makes administration much easier when several packages are installed,
and more so when upgrading or deleting packages.

The point is to keep each “package” (roughly, any program distributed
and installed as a whole; this is unrelated to packages as in apt-get)
in a directory exclusively of its own use under /usr/local/stow, or any
other directory. Then GNU Stow makes symbolic links from the directories
where the system expect the package to be (e.g.: /usr/local/bin) to the
place where the package is actually installed. This way you do not have
to remember which files belong to which package when uninstalling a
manually installed package. GNU Stow will also display a warning if you
try to install (using GNU Stow) packages that have colliding files,
instead of having them override eachother as would happen when doing
“make install”.


Oops - forgot to try GNU Stow. Another time maybe.

Thank you, Mario, for your help. Great discussion.

 - Dan

Re: Stretch vim doesnt cut and paste

[Reco]

Hi.

On Thu, 24 Aug 2017 08:45:19 -0500
David Wright  wrote:

> On Thu 24 Aug 2017 at 12:37:45 (+0300), Reco wrote:
> > Hi.
> > 
> > On Thu, Aug 24, 2017 at 03:38:10PM +1200, Richard Hector wrote:
> > > On 21/08/17 05:31, Reco wrote:
> > > > In jessie and before that one could put needed customizations
> > > > into /etc/vim/vimrc (and it works as of stretch)
> > > > or into /etc/vim/vimrc.local (and it's ignored in stretch).
> > > 
> > > Looking at a stretch box (installed clean, not upgraded), /etc/vim/vimrc
> > > has this at the bottom:
> > > 
> > > " Source a global configuration file if available
> > > if filereadable("/etc/vim/vimrc.local")
> > >   source /etc/vim/vimrc.local
> > > endif
> > > 
> > > So it should be read. Is yours not readable by the user? (I don't have
> > > one at all; I haven't felt the need yet)
> > 
> > No, permissions for /etc/vim/vimrc.local are 644.
> > The problem is (had to use strace to figure this one out) that on vim
> > start /etc/vim/vimrc.local is read first, and
> > /usr/share/vim/vim80/defaults.vim after it.
> > 
> > Therefore any customizations put into /etc/vim/vimrc.local can be
> > overridden by defaults.vim, which is happpening for 'mouse' and
> > 'incsearch' at least.
> > 
> > Unless you forbid vim to interpret defaults.vim at all.
> > It can be achieved by creating user's .vimrc, or 'g:skip_defaults_vim=1'.
> 
> How does all this relate to   man vim   which appears to be
> at least a decade old/out of date? 

vim(1) does not mention defaults.vim, so it must be a case of obsolete
documentation.
That, and I'm too lazy to view vim source.

Reco

Script con output de comando

[Josu Lazkano]

Buenas,

Estoy intentando crear un script para poder comprobar el estado de mi TV
mediante CEC.

Lo que quiero es utilizar la salida de un comando para crear un script. El
comando es el siguiente:

# echo 'pow 0' | cec-client -s -d 1

Y si la TV esta en marcha muestra:

# echo 'pow 0' | cec-client -s -d 1
opening a connection to the CEC adapter...
power status: on

Y si esta apagada muestra:

# echo 'pow 0' | cec-client -s -d 1
opening a connection to the CEC adapter...
power status: standby


Lo que quiero es hacer algo asi:

if [[ $(echo 'pow 0' | cec-client -s -d 1) == "power status: standby" ]];
then
  echo "La TV está apagada"
else
  echo "La TV está en marcha"
fi

Pero no me funciona la condición del IF, ¿como puedo comprar una salida de
un comando?

Agradezco vuestra ayuda.

Un saludo.


-- 
Josu Lazkano

Re: sourceforge ou autre

[Thierry Bugier Pineau]

Le jeudi 24 août 2017 à 16:09 +0200, David Martin a écrit :
> Bonjour
> 
> Je me souviens d'avoir utilisé tucows / freshmeat / sourceforge pour
> trouver des
> petits projets opensource.
> 
> tucows et freshmeat n'existant plus, en connaissez vous d'autre à
> part sourceforge ?
> 
> 
> 

Bonjour

Il y a OW2

https://gitlab.ow2.org/explore

Re: sourceforge ou autre

[Marc Chantreux]

On Thu, Aug 24, 2017 at 04:09:20PM +0200, David Martin wrote:
> Je me souviens d'avoir utilisé tucows / freshmeat / sourceforge pour
> trouver des petits projets opensource.

si ta demande est bien "ou puis-je héberger le code de mon projet libre
sur une platteforme libre", je te répondrais

https://framagit.org

c'est propulsé par gitlab (qui est libre et dont la boite a vraiment un
très bon esprit) et hébergé par framasoft.

what else ...

cordialement,
marc

Re: threading, was Re: DHCP server that itself gets an IP address by DHCP

[Reco]

Hi.

On Thu, 24 Aug 2017 08:25:16 -0500
David Wright  wrote:

> On Thu 24 Aug 2017 at 12:30:35 (+0300), Reco wrote:
> > Hi.
> > 
> > In-Reply-To: <20170824074515.y4z2ummdigk2fcbn@kazuki.local>
> > 
> [...]
> 
> If you type:
> 
> :
> set edit_headers
> 
> you should get the headers included in your composition window,
> and you can then stick the In-Reply-To: amongst its peers.
> (I'm assuming neomutt honours this mutt switch.)

Thanks, I have 'edit_headers' enabled already. I merely put 'Hi' two
lines above I was aiming at.

Reco

Re: Re : problème de tri avec sort

[Samy Mezani]

Le 24/08/2017 à 16:49, nicolas.patr...@gmail.com a écrit :

Parce que le caractère de fin de chaîne est avant tout autre caractère, arobase 
compris.


Merci Nicolas,

Pourrais-tu détailler, je ne comprend pas trop ta phrase.

Merci

Samy

Re : problème de tri avec sort

[nicolas . patrois]

Le 24/08/2017 16:42:51, Samy Mezani a écrit :

> Je m'arrache les cheveux avec sort.

> Soit 2 fichiers texte, avec les contenus suivants :

> Pourquoi le tri est différent dans le 2ème cas ??

> Ma santé mentale vous remercie par avance ! ;-)

Parce que le caractère de fin de chaîne est avant tout autre caractère, arobase 
compris.

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...

problème de tri avec sort

[Samy Mezani]

Bonjour,

Je m'arrache les cheveux avec sort.

Soit 2 fichiers texte, avec les contenus suivants :

$ cat fichier1
"a z"
"a b"
"a"
"ac"

$ cat fichier2
"a z"@t
"a b"@t
"a"@t
"ac"@t

Je trie ces fichiers avec sort :

$ cat fichier1 | sort
"a"
"a b"
"ac"
"a z"

$ cat fichier2 | sort -t "@" -k1
"a b"@t
"ac"@t
"a"@t
"a z"@t

Pourquoi le tri est différent dans le 2ème cas ??

Ma santé mentale vous remercie par avance ! ;-)

Samy

Re: sourceforge ou autre

[hamster]

Le 24/08/2017 à 16:09, David Martin a écrit :
> Bonjour
>
> Je me souviens d'avoir utilisé tucows / freshmeat / sourceforge pour
> trouver des
> petits projets opensource.
>
> tucows et freshmeat n'existant plus, en connaissez vous d'autre à part
> sourceforge ?

tuxfamily

Re: sourceforge ou autre

[David S.]

Le 24.08.2017 16:09, David Martin a écrit :

> Bonjour
> 
> Je me souviens d'avoir utilisé tucows / freshmeat / sourceforge pour trouver 
> des petits projets opensource.
> 
> tucows et freshmeat n'existant plus, en connaissez vous d'autre à part 
> sourceforge ?

Bonjour, 

Tout est github maintenant... 

My 2 cts, 

D.S.

Re: Question to new network device names

[Dan Ritter]

On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:
> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> > However, I'll point out that machines with this many network interfaces
> > are *by far* the exception rather than the rule; indeed, even machines
> > with more than *one* interface each of wired and wireless are reasonably
> > rare.
> 
> In the home desktop space, perhaps.  When you deal with rackmount
> servers, OTOH, four (wired) network ports is pretty standard these days.
> 
> Of course, they're all on the same bus and using identical hardware/
> firmware, so the "order might change based on which drivers load first"
> case still doesn't apply.
> 
> > To the best of my awareness, the rationale for calling this "predictable
> > network interface names" is that, on a single computer which has
> > multiple network interfaces of a given type, this naming scheme makes
> > it possible to predict *from one boot to the next* what the name of each
> > one will be. On such a computer, this is extremely valuable.
> > 
> > By contrast, on a computer which has at most one interface of a given
> > type, this naming scheme provides - so far as I can tell - no advantage
> > at all.
> > 
> > What's more, when working on *multiple* computers of that latter type,
> > this naming scheme makes it impossible to predict *from one computer to
> > the next* what the name of the sole available interface will be.
> > 
> > As such, IMO this naming scheme makes network-interface names
> > significantly *less* predictable in the real-world scenario which is
> > most commonly encountered.
> 
> This closely parallels the move from using /dev/sdXn to UUIDs for
> referring to filesystems.  Probably superior in theory and doesn't cause
> any issues as long as you're dealing with a single machine and
> unchanging hardware configuration... but then you have a drive failure,
> restore your backups onto new hardware, and you're hosed because the
> system wants to boot from a UUID that no longer exists.  (Yes, you can
> recover from that situation - I know because I've had to do it - but it
> doesn't Just Work(TM) effortlessly.)

There are, of course, five different ways to do this (at a
minimum):

1. /dev/sda1 is based on discovery order. Changes in discovery order
may indicate a significant problem that you need to investigate -- or not.

2. /dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S251NXAH217600A is based
on drive type and serial number. This is great if you treat changing a
disk as a serious problem that requires human intervention, and terrible
if you want a replacement disk to be handled automatically.

3. /dev/disk/by-label/sheepdog is based on filesystem labels.  These are
very good for mounting but useless for identifying specific disks,
and they can have collision problems.

4. /dev/disk/by-path/pci-:00:1f.2-ata-1-part1 is based on disk
controller topology. If you are interested in what's in a particular
disk slot rather than the particular disk in it, this is your choice.

5. /dev/disk/by-uuid/428366118125845852 identifies filesystems just
like by-label, and while it is unlikely to have an accidental collision
problem, does have a deliberate collision problem when you have copies
of filesystems.

6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
have their own ideas about what to do and how to do it, which may include
any of the above methods as well as their own peculiarities.

That said, if you have a laptop or a desktop with 1-2 disks, you
are probably going to be perfectly happy with either /dev/sda1 or
LABEL=root-$HOSTNAME addressing.

Getting back to the original point, NIC names -- virtually every computer
has exactly one or two NICs, and is best served by eth0 and wlan0. The
computers with 3-5 NICs are usually best served that way. More complex
naming schemes are helpful when you have a router or switch, and it's
nice that Debian supports that, but hardly a good default.

-dsr-

sourceforge ou autre

[David Martin]

Bonjour

Je me souviens d'avoir utilisé tucows / freshmeat / sourceforge pour
trouver des
petits projets opensource.

tucows et freshmeat n'existant plus, en connaissez vous d'autre à part
sourceforge ?



-- 
david martin

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 09:30, Dave Sherohman wrote:

> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> 
>> However, I'll point out that machines with this many network
>> interfaces are *by far* the exception rather than the rule; indeed,
>> even machines with more than *one* interface each of wired and
>> wireless are reasonably rare.
> 
> In the home desktop space, perhaps.  When you deal with rackmount 
> servers, OTOH, four (wired) network ports is pretty standard these
> days.

The computers I'm considering as what Carroll called the "universe of
discourse" here are "all computers on which this naming scheme is being
used". Whether they are servers or home desktops or business desktops or
smartphones or wireless access points or televisions or coffeepots or
anything else is irrelevant.

(Although of course several of those are unlikely to have anyone looking
at the interface names directly in the first place, so they may also be
irrelevant to the discussion.)

> Of course, they're all on the same bus and using identical hardware/ 
> firmware, so the "order might change based on which drivers load
> first" case still doesn't apply.

That's a detail I don't think I knew about.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Stretch vim doesnt cut and paste

[David Wright]

On Thu 24 Aug 2017 at 12:37:45 (+0300), Reco wrote:
>   Hi.
> 
> On Thu, Aug 24, 2017 at 03:38:10PM +1200, Richard Hector wrote:
> > On 21/08/17 05:31, Reco wrote:
> > > In jessie and before that one could put needed customizations
> > > into /etc/vim/vimrc (and it works as of stretch)
> > > or into /etc/vim/vimrc.local (and it's ignored in stretch).
> > 
> > Looking at a stretch box (installed clean, not upgraded), /etc/vim/vimrc
> > has this at the bottom:
> > 
> > " Source a global configuration file if available
> > if filereadable("/etc/vim/vimrc.local")
> >   source /etc/vim/vimrc.local
> > endif
> > 
> > So it should be read. Is yours not readable by the user? (I don't have
> > one at all; I haven't felt the need yet)
> 
> No, permissions for /etc/vim/vimrc.local are 644.
> The problem is (had to use strace to figure this one out) that on vim
> start /etc/vim/vimrc.local is read first, and
> /usr/share/vim/vim80/defaults.vim after it.
> 
> Therefore any customizations put into /etc/vim/vimrc.local can be
> overridden by defaults.vim, which is happpening for 'mouse' and
> 'incsearch' at least.
> 
> Unless you forbid vim to interpret defaults.vim at all.
> It can be achieved by creating user's .vimrc, or 'g:skip_defaults_vim=1'.

How does all this relate to   man vim   which appears to be
at least a decade old/out of date? I wasn't aware that the
last action of   man foo  ’s $MANOPT should be to append
any or all of /usr/share/doc/foo*/*README* to the manpage.

Cheers,
David.

Re: Debian v9 it's a stretch

[Rob van der Putten]

Hi there


On 24/08/17 15:39, Dan Ritter wrote:


As of Stretch, the standard OpenSSH sshd does not support
Protocol 1, so there's no particular reason to enforce it
by stating Protocol 2.


I assumed as much. It's just a simple way to keep rkhunter happy.


PermitRootLogin now defaults to "prohibit-password", which
means that you can log in as root with a proper SSH key or
via other methods you have set up, but not with a password.
Another useful argument is forced-commands-only, which requires
both public-key authentication and a command="blah blah" option
in the authorized_keys file, and only allows those commands to
be run. If you've got a pull backup system, that can help.


The alternative would be to reconfigure rkhunter.


Regards,
Rob

Re: Debian v9 it's a stretch

[Dan Ritter]

On Thu, Aug 24, 2017 at 02:49:00PM +0200, Rob van der Putten wrote:
> Hi there
> 
> 
> On 22/08/17 21:16, Rob van der Putten wrote:
> 
> > Upgrade from amd64 Jessie (insserv, bare ALSA).
> > I kind of miss xfce-mixer Alsamixergui works, but xfce-mixer looked
> > better.
> 
> I use qasmixer now;
> http://www.sput.nl/software/qasmixer.png
> I removed the xfce4 meta package, since it insists on pulse related stuff.
> There is no xfce4-artwork in Stretch, but the Jessie version works.
> 
> > I'm very happy that Firefox works on bare ALSA.
> 
> > I posted a few things, probably kernel bugs.
> > Apart from that, seamless transition. Even my serial mouse still works.
> > Rkhunter nags a bit about SSH. Even though things seem to be OK. I still
> > have to look into that.
> 
> I added;
> Protocol 2
> PermitRootLogin no
> to /etc/ssh/sshd_config

As of Stretch, the standard OpenSSH sshd does not support
Protocol 1, so there's no particular reason to enforce it 
by stating Protocol 2.

PermitRootLogin now defaults to "prohibit-password", which
means that you can log in as root with a proper SSH key or
via other methods you have set up, but not with a password.
Another useful argument is forced-commands-only, which requires
both public-key authentication and a command="blah blah" option
in the authorized_keys file, and only allows those commands to
be run. If you've got a pull backup system, that can help.

-dsr-

Re: DHCP server that itself gets an IP address by DHCP

[Bob Weber]

On 8/24/17 3:45 AM, Mark Fletcher wrote:
> Hello the list!
>
> [I suppose this is a little bit OT -- but you guys are the best 
> concentration of experts I know, so here goes anyway...]
>
> My local network consists of a bunch of Debian machines of various ages, 
> various iDevices, and the odd Windows machine connected either by wired 
> or wireless ethernet to a Buffalo AirStation, whose WAN port is 
> connected to a mini-ITX machine running LFS which acts as my firewall. 
> The firewall's other interface connects to my cable modem and thence to 
> the internet.
>
> For co-operation with my ISP my firewall gets its external IP address 
> via DHCP from the ISP. I use systemd-networkd to achieve this, and this 
> also takes care of populating /etc/resolv.conf with the name servers 
> provided by the ISP.
>
> So the firewall has 2 interfaces, the external facing one of which gets 
> an IP address from my ISP via DHCP, and the internal facing one has a 
> fixed private IP address.
>
> The AirStation is also set up to get its WAN IP address via DHCP, since 
> A) that is how it comes out of the box, B) the AirStation was for years 
> the last line of defence between my network and the internet and the 
> addition of the dedicated firewall is a relatively recent thing, and C) 
> both the instructions and the web configuration tool are in Japanese 
> and, this being a Japan-market-facing device, the language can't be 
> changed. So I like to futz with the settings on the AirStation as little 
> as possible.
>
> So I run dhcpd on the firewall machine, facing only the 
> local-network-facing interface, so that when the AirStation asks for an 
> IP address, it can be provided with one.
>
> The Airstation is _itself_ running a DHCP server on its LAN ports / 
> WiFi, which is how the rest of my machines on my network get their local 
> IP addresses. So the DHCP server on my firewall in effect services 
> _only_ the AirStation.
>
> My question is this -- I want to pass through the name servers my ISP is 
> providing, to the AirStation when it asks, so that the AirStation can 
> use the ISP's name servers. I did think about running a DNS on the 
> firewall also but this seems unnecessary, and would just create an extra 
> hop to answer DNS queries.
>
> Right now I have the name server IP addresses hard coded in the 
> dhcp.conf config file, which is fine as long as the ISP doesn't change 
> them. But, if the ISP were to change its name servers, the firewall 
> would pick up the changes but as things stand it would continue to 
> provide the old name server addresses to the AirStation, which would 
> mean the rest of the network would no longer be able to resolve DNS 
> queries the AirStation didn't already have cached.
>
> Is there any clever way to pass through the name server settings 
> the DHCP server provides, so that if the ISP should change its name 
> server IP addresses in the future, my local DHCP server would pass along 
> the new addresses when next asked?
>
> In other words, instead of specifying the name server addresses 
> explicitly in the dhcp.conf file, is there a way to specify that they 
> should be taken from the host the DHCP server is running on?
>
> Thanks
>
> Mark
>
>
I have a similar setup as yours but I agree with Reco as I have a caching DNS
server on my firewall machine along with dhcp. It is setup to use  DNSCrypt to
encrypt/protect the connection to opendns (most DNS is in the open and can be
hacked).  I also have a local domain (like mynamehome.net) so I can connect to
my local machines by name (bob.mynamehome.net).  I do have my wireless access
points only serving wireless connections (192.168.xxx.xxx/24) and the wired part
of my network connects directly to the firewall through a switch
(172.16.0.0/16).  I also have firewall rules set up to redirect all connections
going to external DNS servers (google chrome and android devices sometimes make
their own connections to google DNS) to be re-directed to my own DNS server so I
am assured that all DNS is over a encrypted link.  All this allows you to be in
complete control over what DNS server is used and that your ISP isn't
redirecting your internet connections through a botched DNS server returning
incorrect addresses (either on purpose or because of a hacked server).  Of
course the firewall machine has rules that block all external (internet)
connections while allowing internal connections through.  I use shorewall which
makes setting up firewall rules a little easier.

-- 


*...Bob*

Re: Question to new network device names

[Dave Sherohman]

On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> However, I'll point out that machines with this many network interfaces
> are *by far* the exception rather than the rule; indeed, even machines
> with more than *one* interface each of wired and wireless are reasonably
> rare.

In the home desktop space, perhaps.  When you deal with rackmount
servers, OTOH, four (wired) network ports is pretty standard these days.

Of course, they're all on the same bus and using identical hardware/
firmware, so the "order might change based on which drivers load first"
case still doesn't apply.

> To the best of my awareness, the rationale for calling this "predictable
> network interface names" is that, on a single computer which has
> multiple network interfaces of a given type, this naming scheme makes
> it possible to predict *from one boot to the next* what the name of each
> one will be. On such a computer, this is extremely valuable.
> 
> By contrast, on a computer which has at most one interface of a given
> type, this naming scheme provides - so far as I can tell - no advantage
> at all.
> 
> What's more, when working on *multiple* computers of that latter type,
> this naming scheme makes it impossible to predict *from one computer to
> the next* what the name of the sole available interface will be.
> 
> As such, IMO this naming scheme makes network-interface names
> significantly *less* predictable in the real-world scenario which is
> most commonly encountered.

This closely parallels the move from using /dev/sdXn to UUIDs for
referring to filesystems.  Probably superior in theory and doesn't cause
any issues as long as you're dealing with a single machine and
unchanging hardware configuration... but then you have a drive failure,
restore your backups onto new hardware, and you're hosed because the
system wants to boot from a UUID that no longer exists.  (Yes, you can
recover from that situation - I know because I've had to do it - but it
doesn't Just Work(TM) effortlessly.)

-- 
Dave Sherohman

Re: Question to new network device names

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> On 2017-08-24 at 07:52, to...@tuxteam.de wrote:

[...]

> However, I'll point out that machines with this many network interfaces
> are *by far* the exception rather than the rule [...]

If you meant *me*, you're preaching to the choir :)

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

iEYEARECAAYFAlme1IoACgkQBcgs9XrR2kbmbQCfSJirmY8iieqLwjq7MHmRaDpC
s/oAnROGgCiPMwbMGFb3YjUYRRkyQTmb
=h3zq
-END PGP SIGNATURE-

threading, was Re: DHCP server that itself gets an IP address by DHCP

[David Wright]

On Thu 24 Aug 2017 at 12:30:35 (+0300), Reco wrote:
>   Hi.
> 
> In-Reply-To: <20170824074515.y4z2ummdigk2fcbn@kazuki.local>
> 
[...]

If you type:

:
set edit_headers

you should get the headers included in your composition window,
and you can then stick the In-Reply-To: amongst its peers.
(I'm assuming neomutt honours this mutt switch.)

Cheers,
David.

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 07:52, to...@tuxteam.de wrote:

> On Thu, Aug 24, 2017 at 01:11:27PM +0200, Hans wrote:
>
>> Hi folks,
> 
>> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
>> course I know, that this is obviously the newe standard (please correct me, 
>> i 
>> I am wrong).

>> So, what is the status today? How have people accepted the new names also 
>> for 
>> long running systems? 
> 
> I'd say: if you have a box with a huge number of interfaces, or if your
> interface's hardware is brought up dynamically (picture a bunch of USB
> hubs with 16 eth interface adapters at its tips, to have something your
> phantasy can attach to), where the loading order of the corresponding
> kernel modules determine who is first and who is last, whoever is eth0
> and whoever is eth15 may change from boot to boot.
> 
> You don't want that, especially when those are attached to different
> networks (picture a firewall/router...)
> 
> A similar case is when the interfaces come and go (e.g. plugging in and
> out said USB adapters. All this doesn't need to be USB -- in the more
> expensive world you can plug in (and out!) RAM and CPUs, while the
> system is running).
> 
> Predictable names (try to) bring up the "same" interface with the "same"
> name each time (although "same" itself isn't well-defined; IMHO this
> makes a 100% job impossible anyway).

However, I'll point out that machines with this many network interfaces
are *by far* the exception rather than the rule; indeed, even machines
with more than *one* interface each of wired and wireless are reasonably
rare. As such, the scenario in which this naming scheme makes interface
names more predictable is not one which most people will ever encounter.
(...which calls into question the appropriateness of making this scheme
the default.)

To the best of my awareness, the rationale for calling this "predictable
network interface names" is that, on a single computer which has
multiple network interfaces of a given type, this naming scheme makes
it possible to predict *from one boot to the next* what the name of each
one will be. On such a computer, this is extremely valuable.

By contrast, on a computer which has at most one interface of a given
type, this naming scheme provides - so far as I can tell - no advantage
at all.

What's more, when working on *multiple* computers of that latter type,
this naming scheme makes it impossible to predict *from one computer to
the next* what the name of the sole available interface will be.

As such, IMO this naming scheme makes network-interface names
significantly *less* predictable in the real-world scenario which is
most commonly encountered.

On that basis and from that perspective, the choice of "predictable
network interface names" as the label for this naming scheme seems
downright Orwellian.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: Debian v9 it's a stretch

[Rob van der Putten]

Hi there


On 22/08/17 21:16, Rob van der Putten wrote:


Upgrade from amd64 Jessie (insserv, bare ALSA).
I kind of miss xfce-mixer Alsamixergui works, but xfce-mixer looked 
better.


I use qasmixer now;
http://www.sput.nl/software/qasmixer.png
I removed the xfce4 meta package, since it insists on pulse related stuff.
There is no xfce4-artwork in Stretch, but the Jessie version works.


I'm very happy that Firefox works on bare ALSA.



I posted a few things, probably kernel bugs.
Apart from that, seamless transition. Even my serial mouse still works.
Rkhunter nags a bit about SSH. Even though things seem to be OK. I still 
have to look into that.


I added;
Protocol 2
PermitRootLogin no
to /etc/ssh/sshd_config


Regards,
Rob

Re: Re: renommer l'interface réseau

[Pierre Meurisse]

Bonjour,

On Thu, Aug 24, 2017 at 10:03:55AM +0200, Romain wrote:
> Bonjour,
> 
> Je suis nouveau ici, je ne comprends pas pourquoi je ne me suis pas
> inscrit plus tôt car il y a beaucoup de sujet intéressant! Merci à tous
> 
> Merci à Francois Lafont pour sa solution. Je suis entrain de faire des
> testes et voir si je vais intégré cette solution sur mes machines. Car
> c'est vrais que cette nouvelle façon de renommer les interfaces n'aide
> pas quand on fait des scriptes pour paramétrer automatiquement les
> nouvelles machines.
> 
> Pendant mes testes, je constate un petit problème. Lors de mon
> redémarrage, il ne charge pas l'interface réseau: 
> 
> # ip a show eth0
> 2: eth0:  mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 
> Si je fais:
> 
> # ifup eth0
> ifup: unknown interface eth0
> 
> Pourtant j'ai juste suivi les instructions données: 
> 
> # vim /etc/systemd/network/10-eth0.link 
> [Match]
> MACAddress=00:00:00:00:00:00
> 
> [Link]
> Name=eth0
> 
> Puis redémarrer le système.
> 
> Je me suis trompé où?
> 
> Merci pour vos futures réponses
> 
En ce qui concerne ifup eth0, ça me semble normal. Extrait du man de ifup :


DESCRIPTION
   The  ifup  and  ifdown  commands may be used to configure (or, 
respectively, deconfigure) network interfaces based on interface
   definitions in the file /etc/network/interfaces.  ifquery command may be 
used to parse interfaces configuration.


Avec systemd.networkd, on n'utilise pas le fichier /etc/network/interfaces.

J'ai la même réponse pour mon interface qui pourtant fonctionne bien.


-- 
Pierre Meurisse