Re: [DNG] lilo development has ended

[Rick Moen]

Quoting Brad Campbell (lists2...@fnarfbargle.com):

> Details are sketchy now as I made this change in 2005 after 9 good
> years with LILO. I did try very hard to make it work, and it may
> have been an issue with the BIOS ultimately. I actually had a hard
> copy of that particular howto next to my console as I was constantly
> working with LILO and RAID trying to get something that was reliable
> across the plethora of nasty hardware I had to support, so if there
> was a tip in there that might have applied I certainly would have
> tried it more than once. Thankfully I've managed to repress most of
> those memories.

Yes, I know the feeling.  (I'd help if I could, but sadly neither of us
even has a test platform at the moment.)

> The fact remains once bitten, twice shy and it was *much* easier to
> get Grub to work reliably than lilo in this particular instance.

Well, whatever works for you is good.  When I get around to testing
extlinux on the planned pair of RAID1ed SSDs for my new server, I'll
make a point of simulating a device failure and ensure everything works
(and remember to report back here) -- but it's unlikely that I'll get
around to also testing GRUB.  Here in the latter days of 2016 where I do
basic Web searching and find what _purports_ to be a standard solution
to the exact problem you describe, my hunch is that it works.  Perhaps
it's just better documented now than it was then.  Or, alternatively,
maybe it still wouldn't work on your hardware that you used back then.
Impossible to say.

Back in 2002 when I wrote that small Zen of LILO piece for _Linux
Gazette_, I had a very strong feeling that GRUB had widely displaced
lilo for overwhelmingly inadequte an unconvincing reasons -- and that
remains my impression.

> I've used Grub now on all x86 based machines since 2005 and I've never
> bumped up against an issue that has taken more than 5 minutes to
> resolve [...]

I'm happy that it meets your needs.  From my _own_ perspective, what I
see is needlessly complex software that practically begs to be replaced
by something more sparse and devoid of (say) a gratuitously different
device-addressing scheme and the need & ability to read filesystem
semantics.  Accordingly, I look forward to finally getting rid of it,
reversing the lazy system administration error I carelessly permitted
(through inaction) the Debian developers to apply to my systems.

I think the sentiment is widely felt around here that allowing Debian
package maintainers to determine one's system architecture through one's
own inaction has had a bad history, even though various of us might
disagree on particular parts of that.

> I'm not rejecting your experience, I'm just saying *I* found a case
> would reliably break LILO, and after learning how to actually
> configure Grub I've never bumped up against anything similar. That's
> just me however.

Makes sense!

And (your) 'horses for courses' is my second favourite Oz expression,
second only to (of course) 'No worries'.  

In 2010, I was walking across one of the pedestrian bridges across the
Yarra River near the Melbourne Convention Centre, and a pair of
Australians walking the other way asked me if I knew where a particular
hotel was.  I said sure, and offered to walk them over there, as it
wasn't far out of my way.  They politely objected that it was too much
trouble, and I said 'No worries!'  Their expression was priceless, a
sort of 'Hey, I'm not sure you're allowed to say that with a California
accent.'  ;->

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd greybeards

[poitr pogo]

15.08.2016 22:31 "Brian Nash"  napisał(a):
>
> I still don't see the point of using containers, though.

For quite a few modern java developers it is easier to dump their
development workstations into a docker images than write a deployment
specification, i believe.
For quite a few system admins it is easier to pickup a docker image and
leave responsibility to developer than setup application from scratch which
often requires reading documentation, if exists.
And business loves things can be done quicker, read cheaper.
--
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Brad Campbell]

On 16/08/16 11:50, Rick Moen wrote:

Quoting Brad Campbell (lists2...@fnarfbargle.com):


Actually, this exact reason is why I moved from Lilo to Grub a few
moons ago.

It happens *when* one of the primary OS drives dies in your server
and you get a reboot before you have a chance to fix the array.

Example (because this is what triggered the move for me). You have a
RAID1 with your root and boot on it. LILO is installed on those
disks, and you can tell the BIOS to boot from either and it works
just fine. One of those drives goes titsup and before you've had a
chance to deal with it (because it's in an office 13,000km away) you
get a power outage that exceeds the runtime of the UPS. The system
cleanly shuts down and never comes back up because LILO does not
cope with the fact the BIOS has re-ordered the drives.


What a pity you never read the tip in the Boot+Root+Raid+LILO HOWTO that
I referred to upthread:

  # BIOS=line -- if your bios is smart enough (most are not) to detect
  that that the first disk is missing or failed and will automatically
  boot from the second disk, then bios=81 would be the appropriate
  entry here. This is more common with SCSI bios than IDE bios. I
  simply plan on relocating the drive so it will replace the dead
  drive C: in the event of failure of the primary boot drive.

http://www.tldp.org/HOWTO/Boot+Root+Raid+LILO-3.html

That _seems_ to address the exact situation you speak of.  I haven't
tested this, but I might eventually get around to doing a test.
(My systems currently use GRUB 0.9x, and my present intention is to
migrate not back to LILO but rather to extlinux.)


G'day Rick,

Details are sketchy now as I made this change in 2005 after 9 good years 
with LILO. I did try very hard to make it work, and it may have been an 
issue with the BIOS ultimately. I actually had a hard copy of that 
particular howto next to my console as I was constantly working with 
LILO and RAID trying to get something that was reliable across the 
plethora of nasty hardware I had to support, so if there was a tip in 
there that might have applied I certainly would have tried it more than 
once. Thankfully I've managed to repress most of those memories.


The fact remains once bitten, twice shy and it was *much* easier to get 
Grub to work reliably than LILO in this particular instance. After 
spending the couple of hours I needed to come up to speed on Grub, I 
just saw no point persisting with LILO anymore. Under the circumstances 
it was a more reliable solution. I've used Grub now on all x86 based 
machines since 2005 and I've never bumped up against an issue that has 
taken more than 5 minutes to resolve, and certainly nothing that wasn't 
a fat finger issue rather than hardware doing funky stuff.


Horses for courses, I just find Grub reliable enough that I can't see a 
point in moving away from it. If you read the docs it really does work, 
even against pathological BIOS implementations that make LILO fragile.


I'm not rejecting your experience, I'm just saying *I* found a case 
would reliably break LILO, and after learning how to actually configure 
Grub I've never bumped up against anything similar. That's just me however.


I even migrated from Grub 0.9x to Grub2 and I've had nothing but 
unicorns and rainbows there too. Again, another learning curve, but 
nothing a couple of hours didn't sort out. I seem to be the only person 
alive that actually gets along with Grub, but that's ok because it works 
for *me* and that's what matters.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Rick Moen]

Quoting Brad Campbell (lists2...@fnarfbargle.com):

> Actually, this exact reason is why I moved from Lilo to Grub a few
> moons ago.
> 
> It happens *when* one of the primary OS drives dies in your server
> and you get a reboot before you have a chance to fix the array.
> 
> Example (because this is what triggered the move for me). You have a
> RAID1 with your root and boot on it. LILO is installed on those
> disks, and you can tell the BIOS to boot from either and it works
> just fine. One of those drives goes titsup and before you've had a
> chance to deal with it (because it's in an office 13,000km away) you
> get a power outage that exceeds the runtime of the UPS. The system
> cleanly shuts down and never comes back up because LILO does not
> cope with the fact the BIOS has re-ordered the drives.

What a pity you never read the tip in the Boot+Root+Raid+LILO HOWTO that
I referred to upthread:

  # BIOS=line -- if your bios is smart enough (most are not) to detect
  that that the first disk is missing or failed and will automatically
  boot from the second disk, then bios=81 would be the appropriate
  entry here. This is more common with SCSI bios than IDE bios. I
  simply plan on relocating the drive so it will replace the dead
  drive C: in the event of failure of the primary boot drive.

http://www.tldp.org/HOWTO/Boot+Root+Raid+LILO-3.html

That _seems_ to address the exact situation you speak of.  I haven't
tested this, but I might eventually get around to doing a test.
(My systems currently use GRUB 0.9x, and my present intention is to
migrate not back to LILO but rather to extlinux.)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Brad Campbell]

On 16/08/16 00:09, Rick Moen wrote:

Quoting Adam Borowski (kilob...@angband.pl):






Or, the first disk gets assigned a different position.


Which happens when exactly?  Because you're screwing around with
swapping in and out different HBAs?  Well, if you're doing that, see



Actually, this exact reason is why I moved from Lilo to Grub a few moons 
ago.


It happens *when* one of the primary OS drives dies in your server and 
you get a reboot before you have a chance to fix the array.


Example (because this is what triggered the move for me). You have a 
RAID1 with your root and boot on it. LILO is installed on those disks, 
and you can tell the BIOS to boot from either and it works just fine. 
One of those drives goes titsup and before you've had a chance to deal 
with it (because it's in an office 13,000km away) you get a power outage 
that exceeds the runtime of the UPS. The system cleanly shuts down and 
never comes back up because LILO does not cope with the fact the BIOS 
has re-ordered the drives.


Grub copes with this just fine. Slip the drive into any slot and the 
bios will search for the first disk with a viable boot sector and loads 
the grub 1st stage. Grub searches for its second stage, finds it and 
you're good to go.


Of course there might be user error in there, but I spend an *awful* lot 
of time trying to make Lilo work in what were fairly simple failure 
scenarios before giving up and moving to Grub.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[Ralph Ronnquist]

fsmithred wrote on 16/08/16 03:12:

I got an error from the latest make-initramfs.sh about a missing
/root/vdev-initramfs. The actual location of the script is in
/root/vdev-snapshot/root/vdev-initramfs/tools, so I made a symlink:
 ln -s /root/vdev-snapshot/root/vdev-initramfs /root/vdev-initramfs


Yes; bad scripting on my part in the snapshot make-initramfs.sh.
I've added that line to the install-gnuinos-vdev.sh script.

Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - udev is a dead end

[Rick Moen]

[Sorry, this ended up being longer than I'd hoped.]


Quoting Simon Hobson (li...@thehobsons.co.uk):

> Indeed. If you have the source then they can't stop you forking the
> (GPL) project.

Or if you have the complete, buildable source code under any other open
source / free software licence.  This subject comes up occasionally on
the OSI licence-discuss mailing list as 'What is the central idea of
open source?'  My traditional answer is 'The right to fork, accompanied
by the means to do so.'  Which is to say, forking (the right and means
to do it) is the _defining_ trait of open source.


> There was one other thing that came to mind earlier ...
> If ${company} decided to do that, and they had previously distributed
> binaries ... doesn't the GPL mean they are required to provide the
> sources to anyone they've distributed the binaries to ? 

This is going to be one of those difficult conversations where people
keep wanting to rely on wording that implies incorrect concepts embedded
in the culture of technogeeks that cause them to get points of law
wrong.  I'm going to try to explain this precisely as a legal matter.
(Note:  This is not advocacy.  I'm going to explain how the law works,
and how businesses interact with the law.)

Your term 'required' is problematically vague.  Required by whom?  Or
else what?  (Typically open source people don't bother to think about
that.)

Exampleco, Ltd. is distributing binaries of a codebased issued under
(say) GPLv2 licensing terms, and then at some point ceases offering
matching source code to all recipients (or never provided any).  This
divides into two subcases, and the difference is important:

Case A:  Exampleco owns copyright title over all GPL-covered components
of what is being distributed.

Case B:  At least some GPL-covered components are owned by a third party
and are being redistributed by Exampleco.

Ever since adoption of the Berne Convention treaty (and national
legislation to implement it), copyright title has vested in the
creator's ownership automatically at the moment of creation, and
automatically reserves certain 'exclusive' rights to the owner by
default, unless the owner conveys ('licenses') them out to recipients,
attached to instances of the covered work.

Exclusive rights applicable to software[0] are:

o  to make copies
o  to distribute copies
o  to create derivative works[1]

(There are also what are termed 'moral rights of authors' in many
countries including yours, but I'll not cover that here.)

For example, USA Federal law enumerates these exclusive rights in 17
U.S.C. section 106, aka the Copyright Act:
https://www.law.cornell.edu/uscode/text/17/106  Applicable UK statute
law is the Copyright, Designs and Patents Act 1988 (CDPA):
http://www.legislation.gov.uk/ukpga/1988/48  Exclusive rights are
covered in Chapter II.

The enumeration of exclusive rights implicitly creates what one might
call an implied 'default licence':  If I give you an instance of a
program I wrote but state no conveyance of permissions, I am implicitly
authorising your acquisition of the code.  (What I mean, for example, is
that if I list my code as a tarball on my Web site for public access,
and you download it, I am implying that your download is authorised.)  
Your _use_ of the code is outside the scope of copyright law, so you
don't need my permission to do so.  By contrast, in that hypothetical,
you haven't received any of my exclusive rights, so, e.g., your
redistributing the program would be a tort (civil wrong), the tort of
copyright violation.  Torts are not crimes, but I as copyright owner
could haul you into court and enjoin you from further distribution, and
possibly be awarded monetary damages.


Getting back to Exampleco, in Case A, Exampleco's right to distribute
its binaries with or without matching source code is inherent and not
subject to objection on copyright grounds, as each binary is an instance
of a work Exampleco owns, and the firm is merely exercising an exclusive
right.  The firm is free to distribute code instances with any license
attached to each instance it wishes, including ones such as GPLv2 that
say it promises to make matching source available, without bothering to
actually do the latter.  That sort of distribution might be odd and
erratic behaviour, but it doesn't infringe anyone's rights.

In Case A, if you download Exampleco's program, read the docs and
notices, and notice GPLv2 terms, you could attempt to demand the
matching source code, _but_ if Exampleco then ignores you and doesn't
comply, you would have no legal recourse, because Exampleco is not
subject to any obligation:  It doesn't _need_ permissions granted to it
by GPLv2 or anything else.  Its right to make brokenly packaged copies 
(or unbroken ones) is an exclusive right.


Moving on to Case B:  Here, Exampleco has acquired code created and
owned by Otherco.  Otherco as owner offered its work on, say, its
otherco.co.uk Web site, and Exampleco downloaded it.  As 

Re: [DNG] vdev

[aitor_czr]

Hi all,

On 08/15/2016 05:14 PM, aitor_czr wrote:

Hi all,

On 08/15/2016 10:41 AM, aitor wrote:
Yesterday i tried to debianize linux-libre-4.6.2 without libudev-dev. 
Here you are the resulting *.build file:


In summary, the kernel also needs the existence of udev. I will 
remove this requeriment, removing the following lines:


AC_CHECK_HEADER([libudev.h],
[AC_CHECK_LIB([udev], [udev_new],
[LIBS="$LIBS -ludev"],
[AC_MSG_ERROR([Missing udev library!])])],
[AC_MSG_ERROR([Missing /usr/include/libudev.h])])

from the kernel, in *//tools/usb/usbip/configure.ac/*

Jude Nelsons libudev-compat-dev is included as a dependency in 
debian/control, and we don't need to check anything.


As you know, libudev-compat-dev provides /*libudev.h*/ package..., 
and now i'll again without *udev.h*


Cheers,

  Aitor.


The second attempt failed again



Building only the sources of *usb* in the kernel, doing:

make -C tools/usb

it works :)

So, surelly, it's failling due to the location of the dinamical 
libraries of VDEV.



I'll separate libudev-compat-dev in two packages:


1) libudev-compat-dev, containing:

-  /usr/include/libudev.h

-  /lib/${ARCH}-linux-gnu/pkg-config/libudev.pc

-  /lib/${ARCH}-linux-gnu/libudev.so  (pointing to --> 
libudev.so.1.5.2)



2) libudev1, containing:

-  /lib/${ARCH}-linux-gnu/libudev.so.1  (pointing to --> 
libudev.so.1.5.2)


-  /lib/${ARCH}-linux-gnu/libudev.so.1.5.2


I also will have to add in the debian/rules lines like:

DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

CONFFLAGS = \
--with-rootprefix= \
--with-rootlibdir=/lib/$(DEB_HOST_MULTIARCH) \
--with-sysvinit-path=/etc/init.d \
--with-sysvrcnd-path=/etc \
--with-firmware-path=/lib/firmware \

[ ... etc ...]


Cheers,

  Aitor.




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd greybeards

[Brian Nash]

On Mon, Aug 15, 2016 at 10:30:06AM +0200, Adam Borowski wrote:

I like this Slashdot comment:
https://slashdot.org/comments.pl?sid=9525863=52702819


That is quite possibly the greatest burn I have ever seen.

I still don't see the point of using containers, though.
My spam folder is also _full_ of Docker-related messages, leading me to
wonder about a few things:

- Is this the new fad?
- Will it be the "end-all, be-all", like Oberon, OOP, and .NET?
- Will it replace Windows servers as the thing that all the "experts"
think everyone uses?

--
A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort.


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[aitor_czr]

/sd_mod//
//   squashfs//
//   loop/


I'll not use more italicized fonts :)

  Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[aitor_czr]

Hi fsmithred,

On 08/15/2016 08:44 PM, fsmithred wrote:

On 08/15/2016 01:45 PM, aitor_czr wrote:

>
>Hi fsmithred,
>
>On 08/15/2016 07:12 PM, fsmithred wrote:

>>I installed live-boot, live-config, live-boot-initramfs-tools,
>>live-config-sysvinit, and at the end of the installation, when it tried to
>>run update-initramfs, it failed. I forget what the error was.

>
>As i explained, you need a diferent version of initramfs-tools for running
>update-initramfs. Try with this one (it's the same for all architectures):
>
>http://gnuinos.org/initramfs-tools_0.120+deb8u2_all.deb
>
>I still didn't change the version number.
>
>Cheers,
>
>   Aitor.
>
>
>

Errors on installing the deb:

/usr/sbin/mkinitramfs: 261: /usr/share/initramfs-tools/scripts/functions:
Syntax error: "}" unexpected
update-initramfs: failed for /boot/initrd.img-3.16.0-4-amd64 with 2.
dpkg: error processing package initramfs-tools (--install):
  subprocess installed post-installation script returned error exit status 2


The error I got when I ran update-initramfs (before installing the deb)
was a complaint that the initrd had been changed and that I should use -t
to override.

-fsr



I still didn't try the package. I'm working on the kernel and i don't 
want to break my system.


But, these are the changes i made in the /initramfs-tools/:

 - Added Jude's:

/example/initramfs/scripts/init-bottom/vdev/
/example/initramfs/scripts/init-top/vdev/

   in the following paths of the initramfs-tools package:

/usr/share/initramfs-tools/scripts/init-bottom//
/usr/share/initramfs-tools/scripts/init-top//

 - Added Jude's:

/example/initramfs/hooks/vdev/

   in the following path of the initramfs-tools package:

/usr/share/initramfs-tools/hooks//

 - Replaced the initramfs-tool's file:

/usr/share/initramfs-tools/init/ (which starts with udev)

   by Jude's file:

/example/initramfs/init/(which starts with vdev)

 - Added the modules

/sd_mod//
//   squashfs//
//   loop/

   to /usr/share/initramfs-tools/modules/


So, i did't change the /usr/share/initramfs-tools/scripts/functions/

It should work.

Cheers,

  Aitor.






___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[fsmithred]

On 08/15/2016 01:45 PM, aitor_czr wrote:
> 
> Hi fsmithred,
> 
> On 08/15/2016 07:12 PM, fsmithred wrote:
>> I installed live-boot, live-config, live-boot-initramfs-tools,
>> live-config-sysvinit, and at the end of the installation, when it tried to
>> run update-initramfs, it failed. I forget what the error was.
> 
> As i explained, you need a diferent version of initramfs-tools for running
> update-initramfs. Try with this one (it's the same for all architectures):
> 
> http://gnuinos.org/initramfs-tools_0.120+deb8u2_all.deb
> 
> I still didn't change the version number.
> 
> Cheers,
> 
>   Aitor.
> 
> 
> 

Errors on installing the deb:

/usr/sbin/mkinitramfs: 261: /usr/share/initramfs-tools/scripts/functions:
Syntax error: "}" unexpected
update-initramfs: failed for /boot/initrd.img-3.16.0-4-amd64 with 2.
dpkg: error processing package initramfs-tools (--install):
 subprocess installed post-installation script returned error exit status 2


The error I got when I ran update-initramfs (before installing the deb)
was a complaint that the initrd had been changed and that I should use -t
to override.

-fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[fsmithred]

On 08/15/2016 09:36 AM, fsmithred wrote:
> On 08/14/2016 08:12 PM, aitor wrote:
>>
>> Hi fsmithred,
>>
>> On 08/15/2016 12:36 AM, fsmithred  wrote:
>>> richard lucassen wrote on 15/08/16 06:49:
> On Sun, 14 Aug 2016 15:09:54 -0400
> fsmithred  wrote:
>
>>> Moved /etc/vdev/vdev (a symlink) up one level -
>>> I don't think that changed anything.
>
> It should be at /etc/vdev
>
>>> Changed pid file to /run/vdevd.pid -
>>> fdisk now shows the removable drive, I can mount and unmount it.
>>> mouse still doesn't work.
>>> vdev still fails at boot, but if I start it after logging in,
>>> it starts without error.
>
> Hmm, that worked for me and Ralph IIRC. I don't have the Devuan machine
>>> Oops. I completely forgot about the required edits of
>>> /usr/etc/vdev/vdevd.conf which is present in the snapshot but not in the
>>> debs. I've added:
>>>
>>> cp {vdev-snapshot,}/usr/etc/vdev/vdevd.conf
>>>
>>> to the script. My apologies.
>>>
>>> Ralph.
>>
>> The content of the /root/vdev-initramfs is for regenerating the
>> initrd.img; this is the reason why our keayboard and mouses still haven't
>> control. Jude Nelson wrote:
>>
>>
>> 
>>
>> /NOTE: These instructions are Debian- and Devuan-specific, and very
>> hacky.  Use at your own risk.//
>> //
>> //WARNING: Readers are expected to know how to fix a broken initramfs and
>> a broken bootsystem if they try this.//
>> //
>> //Running `make && sudo make install` will get you most of the way towards
>> installing vdev.//
>> //But to use it, you will need to disable udev,//
>> //enable vdev, and rebuild your initramfs to include vdev instead of udev.//
>> //
>> //On Debian and most Debian-derived distributions,//
>> //it is possible to generate an initramfs image with this command://
>> //
>> //$ cd example/ && make initramfs//
>> //
>> //This will generate an initramfs image in `example/`, which can be
>> installed with your bootloader of choice.//
>> //
>> //To enable vdev and disable udev in the init system, the command is //
>> //
>> //$ cd example/ && make install-initscript//
>> //
>> //I'm still working on the packaging scripts that will do all of this
>> automatically./
>>
>> ___
>>
>>
>>
>> I'm working on that. Now i have a computer rebuilding the packages of
>> linux-libre-4.6.2 with libudeb-compat-dev instead of libudev-dev, and i
>> also rebuilt initramfs-tools [*]
>>
>> Hope it works :)
>>
>>   Aitor.
>>
>> [*] You can generate the initrd.img running the
>> /root/vdev-initramfs/tools/mkinitramfs of the snapshot sent by Ralph.
>>
>>
>>
>>
> 
> :) :) :)
> In the words of the apache foundation...  It works!
> Congrats to all those who did the work.
> 
> I made a new installation of devuan to start over.
> 
> I got an error from the latest make-initramfs.sh about a missing
> /root/vdev-initramfs. The actual location of the script is in
> /root/vdev-snapshot/root/vdev-initramfs/tools, so I made a symlink:
>   ln -s /root/vdev-snapshot/root/vdev-initramfs /root/vdev-initramfs
> 
> Mouse and keyboard now work in X, removable drives can be
> mounted/unmounted. I'm going to test the scanner next. Can't test my
> printer now, because there's no parallel port on this laptop.
> 
> What else should be tested?
> 
> -fsr
> 

More testing:

Scanner (ScanMaker 4800) is not found by xsane. If I boot with udev
instead of vdev, scanner works normally.

I installed live-boot, live-config, live-boot-initramfs-tools,
live-config-sysvinit, and at the end of the installation, when it tried to
run update-initramfs, it failed. I forget what the error was.
Note: I did not install live-tools, which diverts update-initramfs.
Then I went back into /root/vdev-initramfs-tools and ran make-initramfs.sh
again, and the live-* stuff got incorporated. I expect I'll be making a
live iso later today.

-fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - udev is a dead end

[Rob Owens]

On Mon, Aug 15, 2016 at 8:34 AM, Simon Hobson 
wrote:

> There was one other thing that came to mind earlier ...
> If ${company} decided to do that, and they had previously distributed
> binaries ... doesn't the GPL mean they are required to provide the sources
> to anyone they've distributed the binaries to ? So removing the sources
> from public repositories would actually be a breach of the GPL (given some
> limitations regarding timing).
> And that raises an interesting problem for other people distributing
> binaries. If (say) I were distributing binaries for ${foo} and relying on
> (say) a git repository for providing the source - where would that leave me
> if those git sources suddenly disappear ?
> Certainly something for anyone building systems to bear in mind. I know
> lots of people who take the attitude - don't keep it, you can download it
> again.
>

My understanding is that the source must be made available for 3 years
after the last binary was made available.
See Section 6:
https://www.gnu.org/licenses/gpl.html
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Rick Moen]

Quoting Adam Borowski (kilob...@angband.pl):

> LILO is anything but 'finished'.  It's not 'stable', either

Cry me a river.

> -- even on simple filesystems where it works, it dies horribly the
> moment any of blocks the kernel was written on gets moved.

Important rule:  If you don't understand how a piece of software works,
you may break it, and indeed probably will do so.  Once again, I will
quote the Zen of LILO from
http://linuxmafia.com/faq/Kernel/zen-of-lilo.html (what I wrote in
_Linux Gazette_ back in 2002):

  A lot of people never learned the Zen of LILO:

  1. /sbin/lilo (the "map installer") is best thought of as a compiler,
  and /etc/lilo.conf as its source code (input).

  2. Therefore, if you change /etc/lilo.conf or any of the files it points
  to, you must run /sbin/lilo before rebooting, to "recompile".

  3. You should always have a "safeboot" stanza in /etc/lilo.conf,
  pointing to a known-good kernel image that you never fool with, as a
  fallback. This ensures that if, e.g., you compile a new kernel but
  accidentally omit console support, you can easily recover.


Complaining that you broke your bootloader because you stupidly moved
one of the things it needs to find, when you knew, or should have known,
that doing so would break the bootloader, is like running out of
gasoline because you failed to refill your tank, and _then_ claiming
that said misadventure proves the car is no good.  Anyone who does that
(and fails to grasp what he/she did wrong and use the 'safeboot'
fallback or a live CD to fix it) IMO really has no business
administering a Unix system.

> Or, the first disk gets assigned a different position.  

Which happens when exactly?  Because you're screwing around with
swapping in and out different HBAs?  Well, if you're doing that, see
foregoing:  You knew, or should knew, that you are likely to chance the
/dev node assignments among your disks, and therefore are going to have
to review _both_ /etc/fstab and your bootloader, if necessary with a
live CD.  That's just life in the big city.  People who cannot handle
that are welcome to go back to Super Nintendo, and I will lend them a
virtual hanky to cry into.



> And on anything new or semi-new, you have EFI and thus GPT, meaning LILO is
> outright worthless.

My bicycle won't fly to the moon, either.  Worthless!

My newest server box to house linuxmafia.com and unixmercenary.net is a
brand new i7-based system from CompuLab, a really sweet machine --
silent, no moving parts, ultra-low power.  And no EFI and no EFT.  And
good riddance to that.


> Even if you have an old machine and your BIOS allows forcing a specific
> ordering of disks, say goodbye to LILO unless your setup is really simple.
> Ie, no RAID, no btrfs, no zfs, no fsfs, no fancier options of xfs.  No
> encryption of any kind.  No LVM.

Works for Me.{tm}

But actually you are totally incorrect to claim that RAID is ruled out.  
Back before Debian threw away my lilo setup and put GRUB 0.9 in its
place, I had my server system booting a RAID1 md mirror pair perfectly
fine for at least a decade.  You just use the map installer on both
disks with an obvious lilo.conf tweak.
http://www.tldp.org/HOWTO/Boot+Root+Raid+LILO-3.html
You didn't know this?  It's been standard documentation for, gosh, about
20 years.


You are also incorrect about the rest of your list, provided that the
/boot filesystem omits the things you list.

Frankly, you should have known this, and avoided the error of making
your ludicruously overbroad claim.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> Which of the preceding is most like a djbdns that does ipv6?

If you like Dan's tinydns for your authoritative DNS, then look no
further than Gerrit Pape's update, 'Debian dbndns', which among
other things adds native IPV6 support.  (Since you asked your question
immediately in response to a list of authoritative-only nameserver
software for Linux, I'm guessing you aren't asking about equivalents to
other pieces within the djbdns suite.)

In general, djbware's not my personal cuppa (in part because I found
administering qmail for a living back in 1999 a strange and oddly
unpleasant experience), but I respect Dan's work with some
qualifications.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> It's possible allright. It's as simple as:
> 
> ip link set dev lo down
> 
> called from /etc/runit/1 or /etc/runit/2 or whatever passes for those
> things in the land of sysvinit.

{sigh}  That's possible, all right.

So is wrapping the server in C4 and lighting a match.

I'm unclear on why you'd do either one.  There are myriad ways to cause
yourself needless pain, but those aren't ones I can see people doing
accidentally.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[aitor_czr]

Hi all,

On 08/15/2016 10:41 AM, aitor wrote:
Yesterday i tried to debianize linux-libre-4.6.2 without libudev-dev. 
Here you are the resulting *.build file:


In summary, the kernel also needs the existence of udev. I will remove 
this requeriment, removing the following lines:


AC_CHECK_HEADER([libudev.h],
[AC_CHECK_LIB([udev], [udev_new],
[LIBS="$LIBS -ludev"],
[AC_MSG_ERROR([Missing udev library!])])],
[AC_MSG_ERROR([Missing /usr/include/libudev.h])])

from the kernel, in *//tools/usb/usbip/configure.ac/*

Jude Nelsons libudev-compat-dev is included as a dependency in 
debian/control, and we don't need to check anything.


As you know, libudev-compat-dev provides /*libudev.h*/ package..., and 
now i'll again without *udev.h*


Cheers,

  Aitor.


The second attempt failed again, getting a lot of:

[...] undefined reference to 'bla bla bla' [...]

I attach the new linux_4.6.2-3_i386.build:

http://gnuinos.org/linux_4.6.2-3_i386.build

No worries :)

I made a huge mistake!!  The following lines were not superfluous:


AC_CHECK_HEADER([libudev.h],
[AC_MSG_ERROR([Missing /usr/include/libudev.h])])


Now, before a third attempt,  i had made sure that all of the missing 
libraries exist in libudev-compat-dev, and maybe in a few hour we will 
have a systemd-free kernel. This is the list:



struct udev *udev_new(void);

struct udev_enumerate *udev_enumerate_new(struct udev *udev);

int udev_enumerate_add_match_subsystem(struct udev_enumerate 
*udev_enumerate, const char *subsystem);


int udev_enumerate_add_nomatch_sysattr(struct udev_enumerate 
*udev_enumerate, const char *sysattr, const char *value);


int udev_enumerate_scan_devices(struct udev_enumerate *udev_enumerate);

struct udev_list_entry *udev_enumerate_get_list_entry(struct 
udev_enumerate *udev_enumerate);


struct udev_device *udev_device_unref(struct udev_device *udev_device);

struct udev_list_entry *udev_list_entry_get_next(struct udev_list_entry 
*list_entry);


const char *udev_list_entry_get_name(struct udev_list_entry *list_entry);

struct udev_device *udev_device_new_from_syspath(struct udev *udev, 
const char *syspath);


const char *udev_device_get_sysattr_value(struct udev_device 
*udev_device, const char *sysattr);


const char *udev_device_get_sysname(struct udev_device *udev_device);

struct udev_enumerate *udev_enumerate_unref(struct udev_enumerate 
*udev_enumerate);


struct udev *udev_unref(struct udev *udev);

struct udev_device *udev_device_new_from_subsystem_sysname(struct udev 
*udev, const char *subsystem, const char *sysname);


const char *udev_device_get_sysattr_value(struct udev_device 
*udev_device, const char *sysattr);


const char *udev_device_get_driver(struct udev_device *udev_device);

const char *udev_device_get_syspath(struct udev_device *udev_device);

const char *udev_device_get_sysname(struct udev_device *udev_device);


Cheers,

  Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Steve Litt]

On Mon, 15 Aug 2016 06:28:31 -0700
Rick Moen  wrote:

> You are correct.  tinydns along with other pure authoritative-only
> nameservers do not cache.  Thus, tinydns (as packaged in either
> djbdns, zinq-djbdns, Debian djbdns/dbndns, N-DJBDNS, or LolDNS),
> dnsjava, gdnsd, Knot DNS, ldapdns, NSD, rbdldnsd, and YADIFA do not
> themselves cache data.

Which of the preceding is most like a djbdns that does ipv6?
 
SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
  Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Steve Litt]

On Mon, 15 Aug 2016 13:47:39 +0100
Simon Hobson  wrote:

> richard lucassen  wrote:
> 
> >> And what I was saying is:  You should run one on modern networked
> >> *ix machine generally.  Because it's 2016.  
> > 
> > I do not agree.  
> 
> +1
> 
> > If the local machine generates quite a bunch of queries
> > than you're right. So, if you have (in 2016) let's say forty servers
> > running in a network, they are all going to query the root servers?
> > I think it's better to have one resolver that does the job for such
> > a network. But you're right to install a caching DNS on a server
> > that makes a lot of queries. I'd use that caching DNS as a
> > forwarder to the central DNS and not one that is going to bother
> > the root-servers.  
> 
> Unless you have just one device on your network, then you should not
> be running a recursive resolver on each of them - that's just being
> antisocial to the internet.

What would happen in djbdns' dnscache if you put your LAN's resolver at
the head of the list of root DNS servers? Is there any way of telling
dnscache "use this root server if at all possible?"

My idea, if it's possible, would be a way to have the office-wide
caching and world resource conservation of a LAN level resolver, but
still have a complete and capable host resolver.

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
  Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Steve Litt]

On Mon, 15 Aug 2016 04:32:45 -0700
Rick Moen  wrote:


> And, honestly, this matter needs to be seen in proper perspective.
> Sometimes a piece of software is relatively simple and well enough
> debugged that it makes just as much sense to call it 'finished and
> stable' as it does 'unmaintained'.

Did I just hear someone mention Fetchmail?

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
  Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] DNS at startup

[Steve Litt]

On Mon, 15 Aug 2016 07:12:02 -0400
Hendrik Boom  wrote:

> On Mon, Aug 15, 2016 at 03:25:01AM -0700, Rick Moen wrote:
> > 
> > There shouldn't IMO be broken DNS any more on modern networked *ix 
> > hosts.  Run a local recursive resolver and list 127.0.0.1 as the
> > first resolv.conf entry.  It's 2016, guys.  
> 
> Why isn't a local resolver the default?  Why do we rely on the ISP to 
> do provide one with DHCP?

Because, even to this day, djbdns tricky to compile-install and
calibrate, and don't EVEN get me started on what distro packages do to
djbdns.

I suppose someone could suggest I go to Bind, but that someone would be
greatly overestimating my IQ: I'd need about 40 additional IQ points to
understand how to work with Bind.

But you bring up an excellent point. Life would be sweeter with an
always-working, local, caching DNS. I *could* create a package made out
of djb's source code (which almost certainly won't change anymore) and
my shellscripts to easily lay down a djbdns, fully configured. I think
there's a patch to make djbdns work with ipv6, so my version2 could do
that.

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
  Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Steve Litt]

On Mon, 15 Aug 2016 04:21:45 -0700
Rick Moen  wrote:

 
> If you cannot reach _127.0.0.1_ because 'your network settings were
> wrong during boot', you have somehow managed to achieve such an epic
> degree of TCP/IP failure that I'm not sure you should be running *ix
> machines.  ;->
> 
> Fortunately, I don't think that's even possible.

It's possible allright. It's as simple as:

ip link set dev lo down

called from /etc/runit/1 or /etc/runit/2 or whatever passes for those
things in the land of sysvinit.

In fact, on all my computers, I have a shellscript called upnet.sh that
makes sure eno1 (or whatever it's called these days) and lo are up, and
eno1 has a hard coded IP address. Or, on one computer where the
existence of eno1 for some reason prevents dhcp on wlp59sq427vette29 (or
whatever it's called), my upnet.sh sets eno1 down.

Crude, but VERY effective, and if you use the new ip commands, it works
on every distro, even (urk) systemd distros.
 
SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
  Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Adam Borowski]

On Mon, Aug 15, 2016 at 04:32:45AM -0700, Rick Moen wrote:
> > > The author has updated their site to say:
> > > 
> > > "NOTE: I will finish development of LILO at December 2015 because of
> > > some limitations (e.g.  with BTFS, GPT, RAID).  If someone want to
> > > develop this nice software further, please let me know ..."
> > > 
> > > So I assume lilo has stopped development altogether from the last
> > > release, and we can look forward to only having the more complex
> > > grub2.
> 
> And, honestly, this matter needs to be seen in proper perspective.
> Sometimes a piece of software is relatively simple and well enough
> debugged that it makes just as much sense to call it 'finished and
> stable' as it does 'unmaintained'.

LILO is anything but 'finished'.  It's not 'stable', either -- even on
simple filesystems where it works, it dies horribly the moment any of blocks
the kernel was written on gets moved.  Or, the first disk gets assigned a
different position.  Only IDE guarantees the order of disks, which means you
can use LILO reliably only on truly museal hardware.

And on anything new or semi-new, you have EFI and thus GPT, meaning LILO is
outright worthless.

Even if you have an old machine and your BIOS allows forcing a specific
ordering of disks, say goodbye to LILO unless your setup is really simple.
Ie, no RAID, no btrfs, no zfs, no fsfs, no fancier options of xfs.  No
encryption of any kind.  No LVM.

> Another example is procmail.

Unlike LILO, I fully agree with you about procmail.  It follows stable Unix
specification, and is mature.

-- 
An imaginary friend squared is a real enemy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[richard lucassen]

On Mon, 15 Aug 2016 06:28:31 -0700
Rick Moen  wrote:

> That aside, I'm entirely unsure what your point is.  This seems
> extremely non-responsive to either the upthread discussion about
> timesync at startup _or_ my assertion to you that modern networked *ix
> machines really ought to have local recursive resolvers in the general
> case.  So, what's the relevance, please?

Never mind, just an example: Bring a server that is configured on
network a.b.c.d/xx to your own network on p.q.r.s/yy and you'll see
what will happen. You'll have to wait until ntp times out before you
are prompted for login.

Anyway, I think we use different solutions for the same problem and
that's fine. Let's get on with vdev instead of creating a huge thread
here :) We're all doing our own right things and we're all doing our own
stupidities :)

Otherwise a site like the Kernel Fuck-o-Meter:

http://www.vidarholen.net/contents/wordcount/

would not exist :)

R.

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[richard lucassen]

On Mon, 15 Aug 2016 13:51:55 +0200
Arnt Karlsen  wrote:

> > No. apt doesn't know about the repository :-P
> 
> ...until you tell it in /etc/apt/sources* ;o)

Yes, but I don't :)

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[fsmithred]

On 08/14/2016 08:12 PM, aitor wrote:
> 
> Hi fsmithred,
> 
> On 08/15/2016 12:36 AM, fsmithred  wrote:
>> richard lucassen wrote on 15/08/16 06:49:
>>> >On Sun, 14 Aug 2016 15:09:54 -0400
>>> >fsmithred  wrote:
>>> >
 >>Moved /etc/vdev/vdev (a symlink) up one level -
 >> I don't think that changed anything.
>>> >
>>> >It should be at /etc/vdev
>>> >
 >>Changed pid file to /run/vdevd.pid -
 >> fdisk now shows the removable drive, I can mount and unmount it.
 >> mouse still doesn't work.
 >> vdev still fails at boot, but if I start it after logging in,
 >> it starts without error.
>>> >
>>> >Hmm, that worked for me and Ralph IIRC. I don't have the Devuan machine
>> Oops. I completely forgot about the required edits of
>> /usr/etc/vdev/vdevd.conf which is present in the snapshot but not in the
>> debs. I've added:
>>
>> cp {vdev-snapshot,}/usr/etc/vdev/vdevd.conf
>>
>> to the script. My apologies.
>>
>> Ralph.
> 
> The content of the /root/vdev-initramfs is for regenerating the
> initrd.img; this is the reason why our keayboard and mouses still haven't
> control. Jude Nelson wrote:
> 
> 
> 
> 
> /NOTE: These instructions are Debian- and Devuan-specific, and very
> hacky.  Use at your own risk.//
> //
> //WARNING: Readers are expected to know how to fix a broken initramfs and
> a broken bootsystem if they try this.//
> //
> //Running `make && sudo make install` will get you most of the way towards
> installing vdev.//
> //But to use it, you will need to disable udev,//
> //enable vdev, and rebuild your initramfs to include vdev instead of udev.//
> //
> //On Debian and most Debian-derived distributions,//
> //it is possible to generate an initramfs image with this command://
> //
> //$ cd example/ && make initramfs//
> //
> //This will generate an initramfs image in `example/`, which can be
> installed with your bootloader of choice.//
> //
> //To enable vdev and disable udev in the init system, the command is //
> //
> //$ cd example/ && make install-initscript//
> //
> //I'm still working on the packaging scripts that will do all of this
> automatically./
> 
> ___
> 
> 
> 
> I'm working on that. Now i have a computer rebuilding the packages of
> linux-libre-4.6.2 with libudeb-compat-dev instead of libudev-dev, and i
> also rebuilt initramfs-tools [*]
> 
> Hope it works :)
> 
>   Aitor.
> 
> [*] You can generate the initrd.img running the
> /root/vdev-initramfs/tools/mkinitramfs of the snapshot sent by Ralph.
> 
> 
> 
> 

:) :) :)
In the words of the apache foundation...  It works!
Congrats to all those who did the work.

I made a new installation of devuan to start over.

I got an error from the latest make-initramfs.sh about a missing
/root/vdev-initramfs. The actual location of the script is in
/root/vdev-snapshot/root/vdev-initramfs/tools, so I made a symlink:
  ln -s /root/vdev-snapshot/root/vdev-initramfs /root/vdev-initramfs

Mouse and keyboard now work in X, removable drives can be
mounted/unmounted. I'm going to test the scanner next. Can't test my
printer now, because there's no parallel port on this laptop.

What else should be tested?

-fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Rick Moen]

Quoting Simon Hobson (li...@thehobsons.co.uk):

> And the reason ISPs run recursive resolvers for their customers ?
> That's easy to answer. 99.99something percent of those customers are
> (in general) not technical people. So if the ISP supplies a
> pre-configured (or auto provisioning) router, which automatically uses
> the ISPs DNS resolvers

Which then become the single biggest network security and network
performance problem many of those customers will ever see, because ISP
nameservers are typically dreadfully slow _and_ subject to pervasive cache
poisoning and other tragedy-of-the-commons problems.  I rest my case.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Rick Moen]

Quoting richard lucassen (mailingli...@lucassen.org):

> Unbound is a (local) caching resolver. Or a (local) recursive resolver.
> But tinydns, which I use for internal resolving is an iterative
> resolver. Tinydns does NOT cache at all.

You are correct.  tinydns along with other pure authoritative-only
nameservers do not cache.  Thus, tinydns (as packaged in either djbdns,
zinq-djbdns, Debian djbdns/dbndns, N-DJBDNS, or LolDNS), dnsjava, gdnsd,
Knot DNS, ldapdns, NSD, rbdldnsd, and YADIFA do not themselves cache
data.

Or at least I'm pretty sure none of them do -- as it would be abnormal
for a pure authoritate-only nameserver to do so.  If you know of any
exceptions, please let me know and I'll amend its entry on
http://linuxmafia.com/faq/Network_Other/dns-servers.html, accordingly.

That aside, I'm entirely unsure what your point is.  This seems
extremely non-responsive to either the upthread discussion about
timesync at startup _or_ my assertion to you that modern networked *ix
machines really ought to have local recursive resolvers in the general
case.  So, what's the relevance, please?


> I do not agree.

You're entitled to your wrong opinion.  ;->

 If the local machine generates quite a bunch of queries
> than you're right. So, if you have (in 2016) let's say forty servers
> running in a network, they are all going to query the root servers?

If you think merely running a recursive nameserver meaningfully burdens
the root nameservers, let alone causes a net increase in network
traffic, then you really need to learn some DNS.

 
> If you do a lot of repetitive queries

No, resolvconf or openresolv (and a local recursive resolver) are simply
beneficial to networked *ix servers in the general case.  Perhaps you
should try it before expressing such opinions.

OTOH, if you would rather not try it, that's your privilege, too.


> Wrong ;-) If your local caching resolver is trying to query the root
> servers and it is not able to find its way out, than you will have a
> timeout problem.

Excuse me, but the example you gave was of wrong entries in resolv.conf.
That seemed extremely contrived, but my answer was:  Don't take a chance
on distant recusive servers being incorrectly specified; put 127.0.0.1 
as your first entry in resolv.conf and run a small recursive nameserver 
(such as Unbound), and then you _cannot_ have that problem.

Now, you're moving the goalposts to 'your network settings were wrong
during boot' more broadly, and saying 'Ah, but Unbound would be
foiled if it were unable to use network access, so you're mistaken.'
Really, Richard?  If you're breaking your system that badly, I believe
you already have a lot bigger problems than Unbound being unable to use
network access.

Unbound would _also_ be unable to reach the root nameservers if you
dropped the running server into a full bathtub of soapy water, as it
turns out.  So, maybe, as the old technical support joke phrases it,
'Don't do that, then.'  ;->


> Let me put it this way, it all in how we call things: a caching or a
> recursive resolver has, when it starts, an empty cache and NO database.
> An iterative resolver has NO cache but just a database.

I'm sorry, but choice of nomenclature matters, and calling a piece of
software 'caching DNS' is saying basically nothing, because that's far
too vague to actually mean anything.  That's what I was saying.  If you
mean recursive, say recursive.  If you mean forwarder, say forwarder.
If you mean iterative, say iterative.  If you mean authoritative, say
authoritative.  Any of those could be 'caching', or not, but saying
'caching' doesn't identify what they actually do.

> dnscache is a caching only resolver
> tinydns is a simple iterative resolver

Is there a reason why you were unable to read any of the several links I
provided where I already explained all of this?


> BTW: I don't use bind. 

I don't like BIND9 either.  Not that that's relevant.

> I like the way Dan Berstein seperates the recursive and the iterative
> resolver.

I like the way the combination of Unbound and NSD separates the
recursive and authoritative servers.  (Iterative service sucks.)

Dan doesn't like me, by the way.  ;->
http://linuxmafia.com/~rick/faq/dan-brandishing-legal-threats
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Simon Hobson]

richard lucassen  wrote:

>> And what I was saying is:  You should run one on modern networked *ix
>> machine generally.  Because it's 2016.
> 
> I do not agree.

+1

> If the local machine generates quite a bunch of queries
> than you're right. So, if you have (in 2016) let's say forty servers
> running in a network, they are all going to query the root servers? I
> think it's better to have one resolver that does the job for such a
> network. But you're right to install a caching DNS on a server that
> makes a lot of queries. I'd use that caching DNS as a forwarder to the
> central DNS and not one that is going to bother the root-servers.

Unless you have just one device on your network, then you should not be running 
a recursive resolver on each of them - that's just being antisocial to the 
internet.

And the reason ISPs run recursive resolvers for their customers ? That's easy 
to answer. 99.99something percent of those customers are (in general) not 
technical people. So if the ISP supplies a pre-configured (or auto 
provisioning) router, which automatically uses the ISPs DNS resolvers 
(typically in the UK, supplied via the PPP sign-in process) - then they can be 
reasonably certain that their customers can "open box, plug in router, get on 
internet" **without** tying up expensive helpdesk man hours.

Tech savvy customers like us can ignore those resolver and do our own thing - I 
too have split horizon DNS.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - udev is a dead end

[Simon Hobson]

Nate Bargmann  wrote:

> Second, clone that repository locally (dead easy with Git).

Which is what I was thinking ...

In an almost exact parallel, at a previous employer they used a business system 
which was effectively bespoke and written in Cobol. The history was that it had 
been written in-house at some large company for their own use, and the devs 
recognised that it had wider application and got permission to sell it to 
others. So they spun off a company selling and supporting this system - each 
installation customised.
It was before my time there (or at least, before I was involved in that side of 
things), but there was some politics and one of the devs tipped off the 
customer (my employer) to make a backup of a load of source files on the system 
- and sure enough, over the next few days/weeks the sources all disappeared off 
our in-house server ... I think the outfit doing support had got into trouble 
and were planning to hike support fees, eventually they folded and the dev that 
tipped us off came and worked for us for a while - we were the only ones left 
using it. After she left, we then had a handful of freelance contractors look 
after it - finding all sorts of "hidden gems"* buried in the code.
A couple of years later we'd switched to an off the shelf system which was much 
more capable !

* As the system didn't have support for various stuff, there were all sorts of 
hacks. One I recall hearing about was a bit of code that basically said "if 
customer code = some_constant then apply 10% discount".


Rick Moen  wrote:

> As has been noted by others, to preserve the ability to fork from other
> versions, wide distribution and mirroring of a codebase's past releases
> (and/or changesets) is necessary.
> 
> I'd like to tell a story about how the world got Portable OpenSSH and
> other completely open source implementations of the secsh protocols.

Thanks, that makes sense and is quite interesting.

> To sum, there are things to beware of and watch for.  Any important
> open source codebase needs to have a significant number of years of its 
> version history widely mirrored, and at least _some_ of the mirrors need
> to be entirely untouchable by the maintainers.  
> 
> Any sudden mysterious code disappearances / unavailability, any
> mysteriously requested assignments of copyright ownership (_especially_
> if they're deceptively called 'Contributor License Agreements' -- and
> I'm looking at you, Canonical, Ltd.), or anything even remotely like
> that should raise immediate red flags and get people independently
> mirroring everything and preparing to fork if necessary.

Indeed. If you have the source then they can't stop you forking the (GPL) 
project.

There was one other thing that came to mind earlier ...
If ${company} decided to do that, and they had previously distributed binaries 
... doesn't the GPL mean they are required to provide the sources to anyone 
they've distributed the binaries to ? So removing the sources from public 
repositories would actually be a breach of the GPL (given some limitations 
regarding timing).
And that raises an interesting problem for other people distributing binaries. 
If (say) I were distributing binaries for ${foo} and relying on (say) a git 
repository for providing the source - where would that leave me if those git 
sources suddenly disappear ?
Certainly something for anyone building systems to bear in mind. I know lots of 
people who take the attitude - don't keep it, you can download it again.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[Arnt Gulbrandsen]

So that when you arrive in the office, you get a view of the world that 
includes the s3kr3t servers in the office (i.e. split horizon), and 
when you later leave the office, those things disappear from your 
view.


Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[richard lucassen]

On Mon, 15 Aug 2016 04:21:45 -0700
Rick Moen  wrote:

> Quoting richard lucassen (mailingli...@lucassen.org):
> 
> > On my workstations I have no caching DNS.
> 
> The term 'caching DNS' doesn't actually mean anything.[1]  All DNS
> software _caches_; even the stub resolver in glibc caches.  I spoke
> of something different and quite specific:  a local recursive
> resolver.

Unbound is a (local) caching resolver. Or a (local) recursive resolver.
But tinydns, which I use for internal resolving is an iterative
resolver. Tinydns does NOT cache at all. And as I use split horizon for
my internal network I have 1 caching resolver and one tinydns:

$ host ssl1.xaq.nl
ssl1.xaq.nl has address 192.168.64.24

$ host ssl1.xaq.nl 8.8.8.8
ssl1.xaq.nl has address 194.109.75.188
ssl1.xaq.nl has IPv6 address 2001:984:c40c:64::24

> And what I was saying is:  You should run one on modern networked *ix
> machine generally.  Because it's 2016.

I do not agree. If the local machine generates quite a bunch of queries
than you're right. So, if you have (in 2016) let's say forty servers
running in a network, they are all going to query the root servers? I
think it's better to have one resolver that does the job for such a
network. But you're right to install a caching DNS on a server that
makes a lot of queries. I'd use that caching DNS as a forwarder to the
central DNS and not one that is going to bother the root-servers.

> > There is one in the network that's the one that is in dhcpd.conf.
> 
> Even DHCP-client hosts can have local recursive resolvers.  This is
> useful:  
> 
> http://qref.sourceforge.net/Debian/reference/ch-gateway.en.html#s-dns-resolvconf
> or 
> http://roy.marples.name/projects/openresolv/index

If you do a lot of repetitive queries

> > And even though you have an caching resolver, if your network
> > settings are wrong during boot, there is nothing to be gained with
> > a local resolver ;-)
> 
> If you cannot reach _127.0.0.1_ because 'your network settings were
> wrong during boot', you have somehow managed to achieve such an epic
> degree of TCP/IP failure that I'm not sure you should be running *ix
> machines.  ;->

Wrong ;-) If your local caching resolver is trying to query the root
servers and it is not able to find its way out, than you will have a
timeout problem.

> Fortunately, I don't think that's even possible.
> 
> [1] Here is an article that may help you with terminology, one I wrote
> after one too many person insisted on using the meaningless term
> 'caching nameserver':  http://linuxmafia.com/~rick/lan.html

Let me put it this way, it all in how we call things: a caching or a
recursive resolver has, when it starts, an empty cache and NO database.
An iterative resolver has NO cache but just a database.

dnscache is a caching only resolver
tinydns is a simple iterative resolver

BTW: I don't use bind. I like the way Dan Berstein seperates the
recursive and the iterative resolver.

R.

R.

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] DNS at startup

[richard lucassen]

On Mon, 15 Aug 2016 07:12:02 -0400
Hendrik Boom  wrote:

> > There shouldn't IMO be broken DNS any more on modern networked *ix 
> > hosts.  Run a local recursive resolver and list 127.0.0.1 as the
> > first resolv.conf entry.  It's 2016, guys.
> 
> Why isn't a local resolver the default?  Why do we rely on the ISP to 
> do provide one with DHCP?

Now you're assuming that apart from a local resolver there exists only
an ISP resolver. On my Linux gateway I run unbound. That's my resolver
for the internal network. That's the place to use split horizon. I
don't use my ISP resolver.

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[Arnt Karlsen]

On Mon, 15 Aug 2016 12:57:40 +0200, richard wrote in message 
<20160815125740.7d4b10cadae0ff71d3c9c...@lucassen.org>:

> On Mon, 15 Aug 2016 10:13:24 +0200
> Arnt Karlsen  wrote:
> 
> > > So I prefer *for the moment*
> > > 
> > > wget .deb
> > > dpkg -i .deb
> > > 
> > > This wil install this particular version and these version will
> > > not be upgraded automatically.
> > 
> > ...until a newer version can be aptitude etc upgrade'd in
> > place... :o)
> 
> No. apt doesn't know about the repository :-P

...until you tell it in /etc/apt/sources* ;o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> On Tue, Jan 19, 2016 at 02:44:59PM -, dev1fanboy wrote:
> > https://lilo.alioth.debian.org/
> > 
> > The author has updated their site to say:
> > 
> > "NOTE: I will finish development of LILO at December 2015 because of some 
> > limitations (e.g. with BTFS, GPT, RAID). If someone want to develop this 
> > nice software further, please let me know ..."
> > 
> > So I assume lilo has stopped development altogether from the last release, 
> > and we can look forward to only having the more complex grub2. 
> 
> lilo development may have ennded, but lilo-installer just got an 
> update in debian unstable.

And, honestly, this matter needs to be seen in proper perspective.
Sometimes a piece of software is relatively simple and well enough
debugged that it makes just as much sense to call it 'finished and
stable' as it does 'unmaintained'.

Another example is procmail.  There's been no functional upstream for
quite a few years, and there are even IIRC two extremely non-credible
alleged security bugs open against it, and yet everyone who's willing to
put up with its idiosyncracies remains happy with it and keeps using it.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Rick Moen]

I wrote:

> The term 'caching DNS' doesn't actually mean anything.[1]  All DNS software
> _caches_; even the stub resolver in glibc caches.
^^

Well, probably I exaggerate.  The stub resolver (Linux DNS client), upon
review, appears to be just about the only piece of software in the chain
that does _not_ cache.  But pretty much any other definitely does, even
nscd, dproxy, dnsmasq, pdnsd, etc.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Hendrik Boom]

On Tue, Jan 19, 2016 at 02:44:59PM -, dev1fanboy wrote:
> https://lilo.alioth.debian.org/
> 
> The author has updated their site to say:
> 
> "NOTE: I will finish development of LILO at December 2015 because of some 
> limitations (e.g. with BTFS, GPT, RAID). If someone want to develop this nice 
> software further, please let me know ..."
> 
> So I assume lilo has stopped development altogether from the last release, 
> and we can look forward to only having the more complex grub2. 

lilo development may have ennded, but lilo-installer just got an 
update in debian unstable.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] DNS at startup

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> Why isn't a local resolver the default?  Why do we rely on the ISP to 
> do provide one with DHCP?

I like the way you think, sir!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Rick Moen]

Quoting richard lucassen (mailingli...@lucassen.org):

> On my workstations I have no caching DNS.

The term 'caching DNS' doesn't actually mean anything.[1]  All DNS software
_caches_; even the stub resolver in glibc caches.  I spoke of something
different and quite specific:  a local recursive resolver.

And what I was saying is:  You should run one on modern networked *ix
machine generally.  Because it's 2016.

> There is one in the network that's the one that is in dhcpd.conf.

Even DHCP-client hosts can have local recursive resolvers.  This is
useful:  

http://qref.sourceforge.net/Debian/reference/ch-gateway.en.html#s-dns-resolvconf
or 
http://roy.marples.name/projects/openresolv/index

> And even though you have an caching resolver, if your network settings
> are wrong during boot, there is nothing to be gained with a local
> resolver ;-)

If you cannot reach _127.0.0.1_ because 'your network settings were
wrong during boot', you have somehow managed to achieve such an epic
degree of TCP/IP failure that I'm not sure you should be running *ix
machines.  ;->

Fortunately, I don't think that's even possible.


[1] Here is an article that may help you with terminology, one I wrote
after one too many person insisted on using the meaningless term
'caching nameserver':  http://linuxmafia.com/~rick/lan.html
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] DNS at startup

[Hendrik Boom]

On Mon, Aug 15, 2016 at 03:25:01AM -0700, Rick Moen wrote:
> 
> There shouldn't IMO be broken DNS any more on modern networked *ix 
> hosts.  Run a local recursive resolver and list 127.0.0.1 as the first
> resolv.conf entry.  It's 2016, guys.

Why isn't a local resolver the default?  Why do we rely on the ISP to 
do provide one with DHCP?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[richard lucassen]

On Mon, 15 Aug 2016 03:25:01 -0700
Rick Moen  wrote:

> Quoting richard lucassen (mailingli...@lucassen.org):
> 
> > When you have no network on the machine ntp notes that there is no
> > network, then it stops AFAIK. But if you have a wrong resolv.conf or
> > something like that you get the above mentioned timeouts.
> 
> Really?  'Wrong resolv.conf or something like that'?  
> 
> There shouldn't IMO be broken DNS any more on modern networked *ix 
> hosts.  Run a local recursive resolver and list 127.0.0.1 as the first
> resolv.conf entry.  It's 2016, guys.

On my workstations I have no caching DNS. There is one in the network
that's the one that is in dhcpd.conf.

And even though you have an caching resolver, if your network settings
are wrong during boot, there is nothing to be gained with a local
resolver ;-)

R.

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[richard lucassen]

On Mon, 15 Aug 2016 10:13:24 +0200
Arnt Karlsen  wrote:

> > So I prefer *for the moment*
> > 
> > wget .deb
> > dpkg -i .deb
> > 
> > This wil install this particular version and these version will not
> > be upgraded automatically.
> 
> ...until a newer version can be aptitude etc upgrade'd in place... :o)

No. apt doesn't know about the repository :-P

-- 
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[Rick Moen]

Quoting richard lucassen (mailingli...@lucassen.org):

> When you have no network on the machine ntp notes that there is no
> network, then it stops AFAIK. But if you have a wrong resolv.conf or
> something like that you get the above mentioned timeouts.

Really?  'Wrong resolv.conf or something like that'?  

There shouldn't IMO be broken DNS any more on modern networked *ix 
hosts.  Run a local recursive resolver and list 127.0.0.1 as the first
resolv.conf entry.  It's 2016, guys.

Unbound:  http://linuxmafia.com/faq/Network_Other/dns-servers.html#unbound
Deadwood:  http://linuxmafia.com/faq/Network_Other/dns-servers.html#deadwood
dnscache:  
http://linuxmafia.com/faq/Network_Other/dns-servers.html#debian-djbdns
PowerDNS Recursor:  
http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdns-recursor

-- 
Cheers,  Arrq uryc qrpelcgvat EBG13?  Nfx zr ubj!
Rick Moen  
r...@linuxmafia.com
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - udev is a dead end

[Adam Borowski]

On Sun, Aug 14, 2016 at 01:19:20PM -0400, Steve Litt wrote:
> On Sun, 14 Aug 2016 09:02:59 +0200
> Didier Kryn  wrote:
> > They only support theur own software; isn't that 
> > legitimate? 
> 
> Half of "their own software" was bought, either by acquisition or by
> hiring project programmers. They then inserted Halloween Code in their
> newly acquired software so it wouldn't run with non-systemd and
> non-Freedesktop stuff. Insertion of Halloween code was characterized as
> "intentional sabotage" by Adam Borowski in this email:
> https://lists.dyne.org/lurker/message/20160813.211227.9340d5a5.en.html

That's not what I meant.

There are three possibilities for breaking users of a competing platform:

1) callous disregard for others
   No malice, just being inconsiderate while making changes that benefit
   users of your platform.

2) goodies that intentionally don't work elsewhere
   Making a feature that could easily be made portable, or even
   intentionally designing it with a detriment in functionality, usable
   only by your users.  This is often Microsoft's tactics, but even the good
   guys sometimes do so: https://www.gnu.org/licenses/why-not-lgpl.en.html

3) outright sabotage
   Planting a logic bomb without even a shred of benefit for the user.
   That's code whose only purpose is to damage someone else.  Kind of
   Microsoft's anti-DR-DOS checks.  Or, recent timebombing of xscreensaver
   by jwz.

Systemd crew tends to do 1), sometimes 2) if an individual coder is
malicious -- but I don't think most of them do so intentionally.
I know of no case they are guilty of 3).

I've read your message in
https://lists.dyne.org/lurker/message/20160813.204905.04e0a813.en.html as 
encouraging 3).  Let's not go there.  Let's not do 2) either -- I don't
expect you to actively pepper your code with sd_notify, but as long as
systemd doesn't break a standard Unix behaviour, your code should work.
As for 1), systemd's components are so volatile and short-lived that
pandering to this week's specification might indeed be too much effort.
Thus, not porting your code to some platform you don't care about or
not working around their bugs or braindeadness (like KillUserProcesses)
is excusable.  But, intentionally breaking things is bad.

-- 
An imaginary friend squared is a real enemy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[aitor]

Hi again,

On 08/15/2016 10:41 AM, aitor wrote:


Hi fsmithred and Tom,

On 08/15/2016 02:29 AM, aitor  wrote:
You can generate the initrd.img running the 
/root/vdev-initramfs/tools/mkinitramfs of the snapshot sent by Ralph.


Running the */root/vdev-initramfs/tools/make-initramfs.sh* script :)

  Aitor.


Yesterday i tried to debianize linux-libre-4.6.2 without libudev-dev. 
Here you are the resulting *.build file:




I didn't attach the link. Here you are the linux_4.6.2-3_i386.build file:

http://gnuinos.org/linux_4.6.2-3_i386.build

Cheers,

  Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[aitor]

Hi fsmithred and Tom,

On 08/15/2016 02:29 AM, aitor  wrote:
You can generate the initrd.img running the 
/root/vdev-initramfs/tools/mkinitramfs of the snapshot sent by Ralph.


Running the */root/vdev-initramfs/tools/make-initramfs.sh* script :)

  Aitor.


Yesterday i tried to debianize linux-libre-4.6.2 without libudev-dev. 
Here you are the resulting *.build file:


In summary, the kernel also needs the existence of udev. I will remove 
this requeriment, removing the following lines:


AC_CHECK_HEADER([libudev.h],
[AC_CHECK_LIB([udev], [udev_new],
[LIBS="$LIBS -ludev"],
[AC_MSG_ERROR([Missing udev library!])])],
[AC_MSG_ERROR([Missing /usr/include/libudev.h])])

from the kernel, in *//tools/usb/usbip/configure.ac/*

Jude Nelsons libudev-compat-dev is included as a dependency in 
debian/control, and we don't need to check anything.


As you know, libudev-compat-dev provides /*libudev.h*/ package..., and 
now i'll again without *udev.h*


Cheers,

  Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] systemd greybeards

[Adam Borowski]

I like this Slashdot comment:
https://slashdot.org/comments.pl?sid=9525863=52702819

-- 
An imaginary friend squared is a real enemy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[Arnt Karlsen]

On Sun, 14 Aug 2016 19:17:45 +0200, richard wrote in message 
<20160814191745.300ec7008bcc1a123a065...@lucassen.org>:
> 
> So I prefer *for the moment*
> 
> wget .deb
> dpkg -i .deb
> 
> This wil install this particular version and these version will not be
> upgraded automatically.

...until a newer version can be aptitude etc upgrade'd in place... :o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Time sync at startup (was: vdev)

[richard lucassen]

On Sun, 14 Aug 2016 17:36:23 -0500
Nate Bargmann  wrote:

> > When you install a new machine? Or whenever you boot and there is a
> > network problem, you will have to wait until ntp times out before
> > you can do anything. Normally it doesn't bother, but when you're
> > mucking about with machines you can run into this problem.
> 
> Interesting.
> 
> I've done plenty of installs or boots without a network and don't
> recall ntp blocking the system startup, at least on Debian and
> derivatives.  I run it on all my computers.

When you have no network on the machine ntp notes that there is no
network, then it stops AFAIK. But if you have a wrong resolv.conf or
something like that you get the above mentioned timeouts.

Anyway, I think OpenNTP is a nice replacement although I have very
little experience with it.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng