from:"Simon"


On 06/06/2016 08:48 PM, Rainer Weikusat wrote:

Simon Walter  writes:

On 06/05/2016 12:16 AM, Rainer Weikusat wrote:

Simon Walter  writes:

[...]


I am adding containers (LXC) and
virtual network to the box, I think I will add an tap and bridge
interface to an /etc/network/interface.d/ file. If I use something
like:

auto br0
iface br0 inet static
  pre-up ip tuntap add dev tap0 mode tap
  pre-up ip link set tap0 up
  post-down ip link set tap0 down
  post-down ip tuntap del dev tap0 mode tap
  bridge_ports tap0
  address 10.1.1.1
  netmask 255.255.255.0
  broadcast 10.1.1.255

And make sure there is the source /etc/network/interface.d/* line in
the interfaces file. Then route with iptables between the a physical
NIC (eth0 for example) and the virtual NIC (tap0) and have all the
containers connected to br0.

Are there any glaring problems with this setup?

This will create a bridge with one virtual network interface bridged to
a character device an application could use to talk 'ethernet' to the
network stack. That's certainly not inherently related to/ useful for
anything-lxc.


I will route the packets to the physical device using iptables,
thereby creating a firewalled private network. I have only tried it
out and not done much research and testing on whether this is actually
secure or not.

You don't need the tap port for that, the bridge will happily work
without any ports statically assigned to it.


And will I be able to set up iptables with just the bridge? I was 
thinking of using shorewall. I've never used it before, but it seems 
like it's configuration is easy to maintain. Therein lies my concern. 
There are zones with interfaces for each zone. For some reason I thought 
a bridge needs to at least have one interface that it is bridging for it 
to be up. Can I bring a bridge up and do iptables stuff with it having 
no interfaces that it bridges?




The machines I'm dealing with use a bridge as 'main interface' a
principally arbitrary number of (lxc) containers connect to via veth
with one physical interface also assigned to the bridge to provide
actual connectivity. It's also possible to do packet filtering between
bridge ports if that's considered to be desirable/ useful.


I want to filter packets between physical NIC (WAN, eth0) and a virtual 
internal network (LAN, br0/tap0???). I am basically creating an isolated 
virtual network with virtual machines all inside one machine. Each 
container will have just enough software to carry out it's place in the 
network. Thereby isolating everything as much as possible, allowing for 
independent updates, modifications, hotswaps, etc.



  'Introduction
site'

http://ebtables.netfilter.org/

One of the advantages of ip(route) over the older, BSD-style tools is
that they can be used to assign an arbitrary number of protocol
addresses to a single interface without employing 'interface aliases'.


Good to know. Thank you!

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

Re: [DNG] ifconfig vs ip

2016-06-06 Thread Simon Hobson

Simon Walter  wrote:

>> You don't need the tap port for that, the bridge will happily work
>> without any ports statically assigned to it.
> 
> And will I be able to set up iptables with just the bridge? I was thinking of 
> using shorewall. I've never used it before, but it seems like it's 
> configuration is easy to maintain. Therein lies my concern. There are zones 
> with interfaces for each zone. For some reason I thought a bridge needs to at 
> least have one interface that it is bridging for it to be up. Can I bring a 
> bridge up and do iptables stuff with it having no interfaces that it bridges?

In Shorewall you would declare the bridge as the interface for a zone. Note 
that Shorewall will filter packets in/out of that interface - not between 
interfaces in the bridge.

>>  want to filter packets between physical NIC (WAN, eth0) and a virtual 
>> internal network (LAN, br0/tap0???). I am basically creating an isolated 
>> virtual network with virtual machines all inside one machine. Each container 
>> will have just enough software to carry out it's place in the network. 
>> Thereby isolating everything as much as possible, allowing for independent 
>> updates, modifications, hotswaps, etc.

How you want to do this affects the answer !

If you want to route traffic between two (or more) bridges, then you just 
declare each bridge as an interface for Shorewall and define the policies/rules 
for traffic between them. This can be done either in the host, or (as I have 
it) as a small VM running as a 2 port router.

If you want to do inter-port security within the switch then that's a bit 
harder and not something I've done. I think you can probably only do that with 
ebtables - and of course you have the dynamic nature of the interfaces to 
consider.

For Shorewall specific questions you'd be better asking over at Shorewall Users 
shorewall-us...@lists.sourceforge.net

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

Re: [DNG] ifconfig vs ip


Adam, Rainer, Simon,

Thanks guys. I thought I knew what I was doing, but now I think I might 
be able to execute this better with all of your advice.


Cheers,

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

Re: [DNG] resolved


On 06/07/2016 05:45 AM, Jim Murphy wrote:

On Mon, Jun 6, 2016 at 2:23 PM, Klaus Hartnegg  wrote:

All programmers please read this, and treat it as a list of things not to do.

https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html

Systemd manages to shoot itself in the foot, and in the elbow, and trigger a 
timebomb, all with one single bullet.

Did anyone follow the "systemd blob" link(within the above
mentioned link) and read any other points including -logind?

This apparently prompted a bug[1] on Debian that turned into a
somewhat long discussion within the bug messages.  It appears
that Debian wanted to turn on, as default, the clean-up feature on
logout. If I read it correctly it would kill background processes
when you log out.  This would result in killing, among other
things, a detached tmux process or a long running background
processes that in the past would have remained running.

So maybe the average user won't be concerned. :(

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394




Yes, that "clean-up" feature was mentioned and discussed and pretty 
vomited on - for obvious reasons. Which is why, and I repeat myself, I 
am so thankful for everyone here. Not everyone drank the coolaid!

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

Re: [DNG] devuan installer and overheating


On 06/07/2016 02:45 PM, emnin...@riseup.net wrote:

Finally i succeeded in installing a devuan ascii into qemu (running on
an archlinux openrc system).

And here too, i noticed that the debian installer is somehow "extreme"
in using ressources. Note this is *NOT* an amd graphics based machine
but a sony_vaio with nvidia graphics. (On another laptop, a samsung
with amd processor and graphics, i could not get installed devuan until
i did not put the machine on top of an icepack!!!).

But nevertheless, installing devuan also this vaio heats up to
something like 85° - but it has a stronger fan than, so the
process went through.

I'm wondering why this problems do not happen with installers of other
distros. If this is repeatable for others too, may be, if some one is
able and prepared to do that, it might be good to check, if there is a
reason why (?)



I have not noticed this. What are the models of your notebook computers?

You could do everyone a favour and debug it a little. Do you know which 
process was spinning the CPU?

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

Re: [DNG] How to acknowledge ported version of Open Source program?


On 06/07/2016 02:51 PM, Hughe Chung wrote:
I've been porting an Open Source program to Python 3.4 for my personal 
use. The original source code written by C language in 2005 has MIT 
license.


...

I'm planning to release it under GPLv3 soon. I will definitely 
acknowledge original author on the license but don't want to include 
the ancient source code in my program.




I think it depends on how much you copied and how polite you are. You 
can say "inspired by", but if your code is structured the same and it 
really is a port, I think you might want to word it differently. Though 
I don't think you need to include such a notice in your source code. If 
you are naming it the same and calling it a Python version, then maybe 
coordinate with the original author. That's just my opinion. I am not a 
lawyer.


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

Re: [DNG] resolved


On 06/07/2016 03:47 PM, Jaromil wrote:
sorry for abstracting the topic, but I definitely see a pattern in 
many contexts. I could bring forward more arguments on why this 
happens in the technology industry at a time in which material 
production techniques reached an innovation peak after 2 decades of 
incredible acceleration.


I am interested in your (and everyone's) musings on the subject. In my 
circle, it is heresy. I suppose I am seeped in the corporate culture and 
find open discussions invigorating.


I do think (was it Mr. Litt that said of) Redhat has a part to play. How 
much of that the you es ay spy agencies were involved is speculation. 
I'd love it if some info was leaked. It would cause everyone to be much 
more critical, think twice, and review code more.


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

Re: [DNG] resolved

2016-06-07 Thread Simon Hobson

Steve Litt  wrote:

> I'm all for corporations making money. I get paid, why shouldn't they?

Indeed. I find it "interesting" to hear some people suggesting they shouldn't 
have to pay for anything - and think that if anyone suggested they shouldn't 
get paid for whatever they do/produce then they might have a different view !
Also bear in mind that a lot of what is "free" is only free and there because 
"someone else" actually paid for it - just look at how many of the major 
projects are led/staffed by people employed by various technology companies to 
produce the "free" stuff.

Eg, while we may deride RH (especially over SystemD), it's true that their 
paying customers do indirectly pay for some of the stuff we use for "free". I 
personally know someone employed by them to work on virtualisation - IIRC he 
works on improvements to things like Qemu.

Of course, we know that a lot of people work on this in their own time - but we 
assume that they are still either employed, or getting a pension, or getting 
some other form of support in order to pay the bills, keep a roof over their 
head, and put food on the table.

> But what if I owned a bicycle shop, and furnished bicycle thieves
> with bolt cutters and five bucks for every bike they boosted, so that
> the recently ripped off would buy a new bike from my shop? That's
> basically what Redhat's doing: Destroying Linux to make their training
> and consulting more valuable.

That does seem a good analogy.

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

Re: [DNG] resolved

2016-06-07 Thread Simon Hobson

KatolaZ  wrote:

> Despite being originally intended as a "guerrilla weapon" (and RMS and
> the others were very careful at designing it), copyleft is indeed the
> only way to keep free software free, forever.

Indeed.
I've heard a few descriptions of RMS - most of them uncomplimentary. Having met 
him, I can see why many people dislike him - he does come across very much as 
the stereotypical geek with no social skills (mind you, me writing that does 
involve a certain amount of "pot, kettle, black" - fill in the rest !)
I can understand his POV, though I'm very much in the pragmatism camp and use a 
mix of free and closed software. But, I respect his position - and I respect 
the fact that without people like him, we would not have the freedoms we have 
now. That's important to remember.

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

Re: [DNG] resolved

On 06/07/2016 06:59 PM, Simon Hobson wrote:

Steve Litt wrote:

I'm all for corporations making money. I get paid, why shouldn't they?

Indeed. I find it "interesting" to hear some people suggesting they shouldn't
have to pay for anything - and think that if anyone suggested they shouldn't get paid for
whatever they do/produce then they might have a different view !
Also bear in mind that a lot of what is "free" is only free and there because "someone
else" actually paid for it - just look at how many of the major projects are led/staffed by people
employed by various technology companies to produce the "free" stuff.

Hold on. I must interject.

Not all programmers are equal. Some are so skilled that to write up a
piece of software and maintain it just for themselves, is not as
difficult as it is for someone like me. If a hobbyist or professional
cannot get the parts s/he needs because the information on the package
is incorrect in some way, then some resort to DIY. It is this group of
DIY hobbyists and professionals and their vision gave us open source
software.

Others in other replies have mentioned some of the pioneers. I respect
and admire them and their fortitude.

It doesn't much to do with producing something directly for sale. The
motivation to produce superior parts might be to enable one to do ones
job better, but those parts were not originally for sale. Redhat is
taking those and selling support for them. Great. Nice. Good. But then
when they start the systemd BS, all the comments about them having
greedy ulterior motives start to make sense. The freeloaders will never
care. After all, they are comfortable with the theft of software.

Eg, while we may deride RH (especially over SystemD), it's true that their paying
customers do indirectly pay for some of the stuff we use for "free". I
personally know someone employed by them to work on virtualisation - IIRC he works on
improvements to things like Qemu.

Yes. My brother works for RH and feeds his children with that money. I
still don't care for RH. I never have and never will. RPM hell may have
been intentional. Just like MS doesn't fix horrible bugs because they
make good money off of support.

Knowing someone in an organization doesn't make it a good organization.

Of course, we know that a lot of people work on this in their own time - but we
assume that they are still either employed, or getting a pension, or getting
some other form of support in order to pay the bills, keep a roof over their
head, and put food on the table.

My first paragraph applies. Only freeloaders are asking for a handout
and those people do not matter to us anyway. Money is no justification
for nefarious action.

My biggest gripe with systemd: How many man hours have been wasted and
will be wasted. There is an lack of wisdom in that project.

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

Re: [DNG] devuan installer and overheating


On 06/07/2016 07:38 PM, emnin...@riseup.net wrote:

Am Tue, 07 Jun 2016 08:33:08 +
schrieb Simon Walter :


I have not noticed this. What are the models of your notebook
computers?

You could do everyone a favour and debug it a little. Do you know
which process was spinning the CPU?

a Samsung NP535U3C (amd processor and graphics)

a Sony Vaio VPCF23S1E (Intel Core i7-2670QM (-HT-MCP-) NVIDIA GF108M)

It always happened when it came to install the software tasks (desktop,
printserver, etc) - apt i'd presume. The fans are going crazy. At first
i thought it might be a problem related to the amd/ati graphics which
unfortunately do not work fine with the free driver. But now, i
realized this also on the Sony Vaio which has nothing to do with amd.
But indeed, on the Vaio it was a qemu installation - but otoh, just to
check, i compiled libre office from source and the machine never got
hotter than 60°. Installing Jessie in qemu the top heat was 87°!

(How can i debug the installation?)


Well, those are certainly powerful enough machines.

Do you have a very fast Internet connection? I would assume the fans go 
crazy, but unless your room is very hot and the machines full of dust, 
they should not crash from overheating.


Let me see...

OK first of all, at least on the version I have 
(devuan-jessie-i386-alpha4-netboot.iso) there is no graphical installer. 
So it's most likely nothing to do with your graphics chip.


Second of all, there is no top on the installer and the busybox version 
of ps that is on the installer is completely striped down.


So you may have to resort to parsing /proc to find the misbehaving 
process. That being said, I don't know if I should say that you should 
write a shell script to parse that info or if you should pick through it 
by hand. It might be simpler to cp top from a compatible installation 
and use that to find the misbehaving process.


Once you find that, then you will know basically what is going on.

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

Re: [DNG] devuan installer and overheating



On 06/08/2016 12:15 PM, Simon Walter wrote:

On 06/07/2016 07:38 PM, emnin...@riseup.net wrote:

Am Tue, 07 Jun 2016 08:33:08 +
schrieb Simon Walter :


I have not noticed this. What are the models of your notebook
computers?

You could do everyone a favour and debug it a little. Do you know
which process was spinning the CPU?

a Samsung NP535U3C (amd processor and graphics)

a Sony Vaio VPCF23S1E (Intel Core i7-2670QM (-HT-MCP-) NVIDIA GF108M)

It always happened when it came to install the software tasks (desktop,
printserver, etc) - apt i'd presume. The fans are going crazy. At first
i thought it might be a problem related to the amd/ati graphics which
unfortunately do not work fine with the free driver. But now, i
realized this also on the Sony Vaio which has nothing to do with amd.
But indeed, on the Vaio it was a qemu installation - but otoh, just to
check, i compiled libre office from source and the machine never got
hotter than 60°. Installing Jessie in qemu the top heat was 87°!

(How can i debug the installation?)


Well, those are certainly powerful enough machines.

Do you have a very fast Internet connection? I would assume the fans 
go crazy, but unless your room is very hot and the machines full of 
dust, they should not crash from overheating.


Let me see...

OK first of all, at least on the version I have 
(devuan-jessie-i386-alpha4-netboot.iso) there is no graphical 
installer. So it's most likely nothing to do with your graphics chip.


OK, well, I just tried the new BETA. It does have a graphical installer. 
You might want to try the text version and see if there is any problem 
with that.


I don't know why there is a graphical installer. My opinion is that If 
it's not taking up too much developers time, then great, but it's really 
not necessary. Hopefully no one is spending much time on it.


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

Re: [DNG] How to acknowledge ported version of Open Source program?




On 06/07/2016 09:35 PM, Arnt Karlsen wrote:

On Tue, 7 Jun 2016 15:31:31 +0900, Simon wrote in message
<57566a43.4050...@gikaku.com>:


On 06/07/2016 02:51 PM, Hughe Chung wrote:

I've been porting an Open Source program to Python 3.4 for my
personal use. The original source code written by C language in
2005 has MIT license.

...

I'm planning to release it under GPLv3 soon. I will definitely
acknowledge original author on the license but don't want to
include the ancient source code in my program.


I think it depends on how much you copied and how polite you are. You
can say "inspired by", but if your code is structured the same and it
really is a port, I think you might want to word it differently.
Though I don't think you need to include such a notice in your source
code. If you are naming it the same and calling it a Python version,
then maybe coordinate with the original author. That's just my
opinion. I am not a lawyer.

..11 years with Groklaw.net has thaught me to be a little harsher;
you cannot "port" a program written under one license (MIT), under
another license, unless that first license has language that allows
such "relicensing" under other licensing terms.


The MIT license must be retained. Though it does say you can sub-license.

Since Chung's new version is written in Python, wouldn't it be 
considered a different piece of software? I don't think a re-write in 
another language of something licensed under the MIT license can even be 
considered a derivative, much less a copy.


I think a port is normally considered what you do when you recompile 
code for another architecture. (https://en.wikipedia.org/wiki/Porting) 
says so. I am aware that some say, "port such and such to PHP," but I 
think that is technically incorrect.


"The term is not generally applied to the process of adapting software 
to run with less memory on the same CPU and operating system, nor is it 
applied to the rewriting of source code in a different language 
<https://en.wikipedia.org/wiki/Programming_language> (i.e. language 
conversion or translation)."


Of course Wikipedia is not the authority on all knowledge. ;)

Simon

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

Re: [DNG] Killing background processes on logout [was Re: resolved]


On 06/08/2016 07:49 PM, KatolaZ wrote:

[sorry for the long reply]


Very well put.



Killing all the processes at logout should be easily doable using
cgroups (which existed much before Poettering got his bachelor
degree), and is indeed easily doable with screen, nohup, and hundred
of similar amenities. Those *mechanisms* exist already, and new ones
can and should be introduced as needed, to complement the existing
ones, so that they can be combined in thousands of different new ways,
to serve the needs of different and emerging use cases. But it is not
possible to enforce the policy "all the processes that want to survive
have to use a precise mechanism", which in the meanwhile breaks
backward compatibility with other mechanisms and other policies. This
is not innovation. This is just breaking things for the sake of it.



IMHO, systemd should probably be called gnomed and then employ all the 
well known, well documented APIs of the system(s if it is to be useful 
on other OS that Gnome might run on) to do it's thing.


By not employing those existing mechanisms, the authors of systemd are 
guilty of moving Linux systems farther away from POSIX and Unix then 
they already are. Linux might not be a true Unix for a few reasons, but 
those reasons have been deliberated over and there is no need to be in a 
hurry to break things. If it were not for projects like Devuan, Linux 
may really become something a Unix user cannot use comfortably and/or 
fluently. I should not have to learn to drive again just because the 
engine of a car has become more efficient. To the business man, it might 
make sense to put forth this excuse, because he gets to rip you off, but 
to the rest of us it is what is called sh177y engineering.

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

Re: [DNG] How to acknowledge ported version of Open Source program?

2016-06-08 Thread Simon Hobson

Jack L. Frost  wrote:

> Yeah, I was going to say that too: a rewrite in another language is a
> completely new piece of software ...

I wouldn't be too sure.
It will vary considerably on the details.
At one extreme, you look at what the original is doing and write new code to do 
the same manipulations on data - but in your own way. *Probably* OK.
At the other extreme, you look at what the source is doing and merely 
"translate" that into another language making minimal changes. *Probably* not 
OK.

Not to mention, in many jurisdictions, people can't assume they can afford to 
win in court !

I'd suggest the sensible way is, as already suggested, to contact the original 
developer/copyright holder. If it's a single person, they may be happy to 
extend the licensing anyway and completely remove any debate or risk.

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

Re: [DNG] Killing background processes on logout [was Re: resolved]

2016-06-08 Thread Simon Hobson

Edward Bartolo  wrote:

> One strategy would be to deny
> server access to anyone not using systemd. This would force Devuan to
> set up an entirely independent infrastructure. I think, this may do
> some serious disruption: be prepared as Devuan is not yet totally
> divorced from Debian.

I suspect that even for the most rapid of systemd fanboys, getting your licence 
to use GPL software revoked* for breaking the terms of the licence is probably 
going over the line.

* And then, getting all your US based infrastructure shut down when your 
hosting companies get DMCA requests over the (now) illegally distributed 
software.

Yes, as said before, the GPL and "copyleft" is indeed a powerful weapon.

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

Re: [DNG] Killing background processes on logout [was Re: resolved]


On 06/09/2016 07:07 AM, Dan Purgert wrote:

Didier Kryn wrote:

[snip]

 I cite:
"Systemd and cgroup developers are working together to turn systemd into a
global cgroup manager that creates higher-level control knobs and prevents
direct access to the kernel. Many Systemd changes are already released
while cgroup changes are set to be merged into the upstream kernel.
Much work still remains, however."

Yet another thing that systemd is getting its tentacles into ... wonder
when the majority of users will say "enough is enough" with it?




They will not. The majority of users are freeloaders. So we may end up 
using a BSD. But not today. GNU/Linux is still available.

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

Re: [DNG] Killing background processes on logout [was Re: resolved]


linuxvoice.com/interview-lennart-poettering

It's an old article, but as I read, I realized how much I disagree with 
Lennart. TBH, he sounds like an Apple fan.


Now we get controversial, because those who like to feel smart, yet 
don't know much, feel empowered by AI. Those who don't feel smart, but 
want to be smart, don't like AI, because it means they can't learn. 
Admins and technicians alike need to be able to know what is going on. 
So we hate AI. I hate it when a handful of the desktops in an office 
running Windows >XP decide that the network is unsafe and just deny 
access somehow with some undocumented mechanism. I can ping. I can 
resolve. But none of the desktop programs work because of the yellow 
exclamation mark. Some command line fu to force the system into a state, 
and we're back in business.


A few choice quotes:
"The Unix misconception is a pretty interesting one, because most people 
who say Systemd is un-Unixish have no idea what Unix is actually like.


What’s typical for Unix, for example, is that all the tools, the C 
library, the kernel, are all maintained in the same repository, right? 
And they’re released in sync, have the same coding style, the same build 
infrastructure, the same release cycles – everything’s the same. So you 
get the entire central part of the operating system like that. If people 
claim that, because we stick a lot of things into the Systemd 
repository, then it’s un-Unixish, then it’s absolutely the opposite. 
It’s more Unix-ish than Linux ever was!"


Nice one pulling the wool over the reporters eyes. What people mean by 
un-Unixish has nothing about releasing code and coding style. It has 
everything to do with one tool for one job. Lennart knows this and he is 
being intellectually and academically dishonest. I wouldn't hire him. 
Well, he does seem sly enough for sales.


"We thought: if you want to solve this properly, then you need to let 
the computer do these things. And this had lots of different effects: 
for example, Upstart always maximised what happened on the system, while 
we think you always have to minimise what happens."


I don't like Upstart or Cannonical, but, here he says what most admins 
do not like. Why would you want to minimize what happens? He is like the 
new Steve Jobs. "You shall like what I decide is best for you. You don't 
need options. I know how everyone will use the machine." These guys just 
want to be worshiped. They don't play well with the other kids.


Simon

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

Re: [DNG] ifconfig vs ip


Hi everyone,

After some testing, I have a question about an option in 
/etc/default/shorewall:

wait_interface
If I add the bridge interface to that line, shorewall will not start 
unless a container is brought up. I suppose that is why I was thinking 
of bridging the bridge inerface with a tap interface so that it's always 
available.


It seems that bridges do not start with ifup (-a) unless one of their 
bridged interfaces are up.


Or I could do as Mr. Hobson does and run shorewall in a container. Would 
that actually be a more insulated "secure" approach?


Thanks and kind regards,

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

Re: [DNG] ifconfig vs ip

2016-06-09 Thread Simon Hobson

Simon Walter  wrote:

> After some testing, I have a question about an option in 
> /etc/default/shorewall:
> wait_interface
> If I add the bridge interface to that line, shorewall will not start unless a 
> container is brought up. I suppose that is why I was thinking of bridging the 
> bridge inerface with a tap interface so that it's always available.
> 
> It seems that bridges do not start with ifup (-a) unless one of their bridged 
> interfaces are up.

I don't think I've used "isolated" bridges so it's never come up for me. Do you 
need to specify wait_interface for it ?

> Or I could do as Mr. Hobson does and run shorewall in a container. Would that 
> actually be a more insulated "secure" approach?

"Security" is a relative thing, and depends on your priorities. Putting the 
firewall in it's own VM would improve isolation (the netfilter rules will be 
processed in the VM) - but the traffic still goes through the host Dom0. You 
can, AIUI, reduce this latter bit by running a separate driver domain to own 
the virtual interfaces and further insulate the traffic from Dom0.
You could also use PCI passthrough to make a NIC owned by a VM - so Dom0 
doesn't handle the packets.

But this all depends on your priorities (or level of paranoia !). I don't think 
handling the network traffic in Dom0 is "insecure" - just not as secure as if 
it doesn't handle it.

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

Re: [DNG] ifconfig vs ip

2016-06-09 Thread Simon Walter

On 06/09/2016 10:24 PM, Simon Hobson wrote:

Or I could do as Mr. Hobson does and run shorewall in a container. Would that actually be 
a more insulated "secure" approach?

"Security" is a relative thing, and depends on your priorities. Putting the 
firewall in it's own VM would improve isolation (the netfilter rules will be processed in 
the VM) - but the traffic still goes through the host Dom0. You can, AIUI, reduce this 
latter bit by running a separate driver domain to own the virtual interfaces and further 
insulate the traffic from Dom0.
You could also use PCI passthrough to make a NIC owned by a VM - so Dom0 
doesn't handle the packets.

But this all depends on your priorities (or level of paranoia !). I don't think handling 
the network traffic in Dom0 is "insecure" - just not as secure as if it doesn't 
handle it.

Indeed. And if I was really paranoid, I might use something other than 
LXC, since other technologies isolate even more. Though, I might put the 
firewall in it's own container even if just for the sake of 
modularity/maintenance.

On 06/10/2016 08:06 AM, Greg Olsen wrote:
> On 2016-06-09 02:50, Simon Walter wrote:
>> It seems that bridges do not start with ifup (-a) unless one of their
>> bridged interfaces are up.
>
> That doesn't sound right.
> Here's a bridge I have defined for LXC containers:
>
> auto lxcbr0
> iface lxcbr0 inet static
>  pre-upbrctl addbr $IFACE
>  address   10.0.0.1
>  netmask   255.255.0.0
>  network   10.0.0.0
>  broadcast 10.0.255.255
>  bridge_stp off   # disable Spanning Tree Protocol
>  bridge_waitport 0# no delay before a port becomes
> available
>  bridge_fd 0  # no forwarding delay
>  upip link set $IFACE up
>  down  ip link set $IFACE down
>  post-down brctl delbr $IFACE
>
> The IP address is assigned as part of the bridge definition. Like
> Rainer said, no tap device needed.
>
> Due to the "auto lxcbr0" the bridge is brought up automatically
> during system startup.
> It comes up just fine with *no* containers running.

Though, you do need to specify the bridge to be created and destroyed, 
which is something I thought was done automatically. It is when there 
are ports specified. As Rainer pointed out, when bridge_ports is "none", 
then the bridge device is created automatically and one not need to 
create it and destroy it pre-up and post-down. Though it seems to do it 
explicitly is a bit faster. I am not sure which is better or if there 
are any side affects.

> Here's the ifstate resulting from ifup:
> # grep lxcbr0 /run/network/ifstate
> lxcbr0=lxcbr0
>
> I've never had the need to specify a *bridge* interface on the
> Shorewall wait_interface list.
>
> /etc/default/shorewall "wait_interface" is used when you need to
> detect a dynamically assigned IP.  I.e. so
> 'find_first_interface_address' can return an IP, which it can't do if
> one hasn't been assigned yet.
>
> However as can be seen in the example above, it already has an IP and
> therefore no need for Shorewall to *wait* for one to be assigned. I
> suggest leaving the bridge off the wait list.

OK, that's good to know. I couldn't find documentation for it. I wasn't 
sure what it was for.

> In my setup Dnsmasq is configured to listen on the bridge IP.  When
> dnsmasq starts up, the bridge is already there. The LXC containers
> are then DHCP assigned the bridge IP as their default GW.  And the
> kernel handles the routing from there, provided IP forwarding is
> turned on.
>
> To have Shorewall turn on forwarding for you, just specify
> "IP_FORWARDING=On" in /etc/shorewall/shorewall.conf.

Yes, I did notice this and have that set up. In fact it was working in 
the convoluted way with a tap interface. However, thanks to everyone's 
advice, the end result will probably be much better.

Thanks and kind regards,

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

[DNG] LXC template for Devuan

2016-06-09 Thread Simon Walter


Hi all,

I am wondering if it is a good idea to submit a modified version of the 
debian template to the upstream LXC project.


I am not sure who wrote those scripts. It seems like that is part of LXC 
source. So I am guessing it has nothing to do with the Debian LXC 
package maintainer.


Also, I wouldn't want to submit something for Devaun to LXC without at 
least one other LXC + Devaun user taking a look at it and kicking the tires.


Or maybe someone has already modified the debian template for Devuan.

Checking (/usr/share/lxc/templates/lxc-debian), it looks like sysvinit 
is in use:

# configure the inittab
cat < $rootfs/etc/inittab
id:3:initdefault:
si::sysinit:/etc/init.d/rcS
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
1:2345:respawn:/sbin/getty 38400 console
c1:12345:respawn:/sbin/getty 38400 tty1 linux
c2:12345:respawn:/sbin/getty 38400 tty2 linux
c3:12345:respawn:/sbin/getty 38400 tty3 linux
c4:12345:respawn:/sbin/getty 38400 tty4 linux
p6::ctrlaltdel:/sbin/init 6
p0::powerfail:/sbin/init 0
EOF

Hence there is a bug about LXC containers not working with systemd yet.

So maybe this is a good base and just the MIRROR needs changing.

Kind regards,

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

Re: [DNG] LXC template for Devuan

2016-06-09 Thread Simon Walter


(A little update)

What I did was:
cp /usr/share/lxc/templates/lxc-debian /usr/share/lxc/templates/lxc-devuan
cp /usr/share/lxc/config/debian.common.conf 
/usr/share/lxc/config/devuan.common.conf
cp /usr/share/lxc/config/debian.userns.conf 
/usr/share/lxc/config/devuan.userns.conf


I don't know if the last one is used. It doesn't seem to be referenced 
in the template.


Then I:
- removed the function configure_debian_systemd.
- changed the MIRROR to https://auto.mirror.devuan.org/merged/
- removed debian from all the function names
- changed debian to devuan in all the messages

Then I created a container the new template.

There were some warnings.

insserv: warning: current start runlevel(s) (empty) of script 
`checkroot.sh' overrides LSB defaults (S).
insserv: warning: current stop runlevel(s) (S) of script `checkroot.sh' 
overrides LSB defaults (empty).
insserv: warning: current start runlevel(s) (empty) of script 
`checkroot.sh' overrides LSB defaults (S).

update-rc.d: error: umountfs Default-Start contains no runlevels, aborting.
insserv: warning: current start runlevel(s) (empty) of script 
`hwclock.sh' overrides LSB defaults (S).
insserv: warning: current stop runlevel(s) (0 6 S) of script 
`hwclock.sh' overrides LSB defaults (0 6).

update-rc.d: error: cannot find a LSB script for hwclockfirst.sh

These are the same warning encountered with the Debian template. So if 
anything we should fix that for Devuan, but it doesn't seem to be a problem.


I then modified the containters config and network settings and it 
started and seems to work fine.


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

Re: [DNG] ifconfig vs ip

On 06/10/2016 03:55 PM, Greg Olsen wrote:

On 2016-06-10 06:34, Greg Olsen wrote:
[snip]
 > The only side-effect are the extra messages during ifup with
 > "bridge_ports none":
 >
 > iface testbr1 inet static
 > bridge_ports none
 > address 10.91.0.1
 > netmask 255.255.0.0
 > network 10.91.0.0
 > broadcast 10.91.255.255
 > bridge_stp off   # disable Spanning Tree Protocol
 > bridge_waitport 0# no delay before a port becomes
available
 > bridge_fd 0  # no forwarding delay
 > upip link set $IFACE up
 > down  ip link set $IFACE down

Sorry to respond to my own post here:
I meant to remove the up/down statements in the example above. Those
aren't needed either when using "bridge_ports none".

No, that's cool and thanks for explaining. I think the up/down 
statements are not needed at all. It seems to work without them - 
whether using pre/post line or "bridge_ports none".

Using "bridge_ports none" and then having post line delete the bridge 
does however cause message to say the device does not exist.

I am a bit confused about the distros relationship with ifupdown. Isn't 
/etc/network/interfaces Debian specific? So I am guessing the ifup/down 
is a different program on say CentOS. I should try to stay relevant even 
though I use mostly Devaun now.

Cheers,

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

Re: [DNG] LXC template for Devuan


On 06/10/2016 05:11 PM, KatolaZ wrote:

On Fri, Jun 10, 2016 at 12:41:36PM +0900, Simon Walter wrote:

Hi all,

I am wondering if it is a good idea to submit a modified version of the
debian template to the upstream LXC project.

I am not sure who wrote those scripts. It seems like that is part of LXC
source. So I am guessing it has nothing to do with the Debian LXC package
maintainer.


Hi Simon,

I think you might want to liaise with Greg Olsen on Devuan support for
LXC. You probably know that there is already some material on the
gitlab:

   https://git.devuan.org/gregolsen/lxc-devuan



Nice. Thank you for pointing that out. I see Greg has already done most 
of this.


Greg, on the page there is:
$ git clone g...@git.devuan.org:gregolsen/lxc-devuan.git

For read access maybe it would work better if it was:
$ git clone http://git.devuan.org/gregolsen/lxc-devuan.git

I couldn't clone it using the git protocol (if that is what is called).

I will give the templates a go now.

Do you have plans to include that into an upstream release? Do you know 
if those are maintained by a Debian maintainer or by the LXC project 
itself? I am guess that those are distro specific. So would that mean 
that the Debian maintainer might not be interested in the Devuan 
templates? Of course Debian users may very well want a Devaun 
containers. If so, then it would be nice if there was an LXC package for 
Devuan so we don't need to clone a git repo to have those templates.


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

Re: [DNG] LXC template for Devuan


On 06/10/2016 05:35 PM, Simon Walter wrote:

On 06/10/2016 05:11 PM, KatolaZ wrote:

On Fri, Jun 10, 2016 at 12:41:36PM +0900, Simon Walter wrote:

Hi all,

I am wondering if it is a good idea to submit a modified version of the
debian template to the upstream LXC project.

I am not sure who wrote those scripts. It seems like that is part of LXC
source. So I am guessing it has nothing to do with the Debian LXC
package
maintainer.


Hi Simon,

I think you might want to liaise with Greg Olsen on Devuan support for
LXC. You probably know that there is already some material on the
gitlab:

   https://git.devuan.org/gregolsen/lxc-devuan



Nice. Thank you for pointing that out. I see Greg has already done most
of this.

Greg, on the page there is:
$ git clone g...@git.devuan.org:gregolsen/lxc-devuan.git

For read access maybe it would work better if it was:
$ git clone http://git.devuan.org/gregolsen/lxc-devuan.git

I couldn't clone it using the git protocol (if that is what is called).

I will give the templates a go now.


I had some issues:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Over ten times repeated, but more importantly:
lxc_container: Failed to parse config: lxc.include = 
/usr/share/lxc/config/common.conf


lxc_container: Failed to parse config: lxc.include = 
/usr/share/lxc/config/devuan.common.conf


By the way, I have Devuan alpha4 installed. So maybe that is the issue 
there. Though, with my modified config and templates, I didn't have 
those errors.


Let me know if there is anything I can do to help test etc.

Many thanks,

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

Re: [DNG] LXC template for Devuan


On 06/10/2016 06:16 PM, Jaromil wrote:

On Fri, 10 Jun 2016, Simon Walter wrote:

I will give the templates a go now.


thanks!



I am going to try Greg's template on the BETA release.

My simple edit on the alpha4 worked fine, but Greg's templates didn't 
work as well. So I am trying with BETA.



Do you have plans to include that into an upstream release?


yes, especially if more than one person gets involved so we have some
degree of peer review. Also please note we are in the process of
setting up a builder server on the premises of our HQ in Amsterdam and
all its setup is based on LXC. Hellekin is currently going through its
configuration and I can hear little sounds of satisfaction and success
across the day coming from his desk. But I'm not aware if Hk is using
Greg's template.


So you are bootstraped? Using Devuan to build Devuan?




If so, then it would be nice if there was an LXC package for Devuan
so we don't need to clone a git repo to have those templates.


sure, if such a team forms and a .deb package is ready, made through a
somehow collective process involving more than one developer, it will
be certainly included in our repositories.



OK, wonderful. I am doing lots of tests for my work too. So I will 
definitely be sending feedback around.


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

Re: [DNG] secure boot

2016-06-12 Thread Simon Hobson

Hendrik Boom  wrote:

> How *do* we deal with secure boot?  I am terrified of buying a new 
> machine because  I'm afraid I won't get to install anything on it 
> wxcept for an OS from one of the big companies that have 
> sweetheart deals with Microsoft.

Well (under UK law at least, other EU countries should have something 
equivalent, dunno about other places ...) you mention when buying it that you 
intend to install (say) Devuan Linux. If it can't run it, and the vendor didn't 
warn you at time of purchase, then you can insist that they : repair it, 
replace it, or refund it.
That's basic consumer protection legislation, required by EU directive and 
implemented by national laws in each EU country.

The new result is that you'll probably have to send it back - but then the 
seller has an opened & returned product and loses out. It is our duty to do 
this and make it a cost to sell "defective" products.

Rowland Penny  wrote:

> I don't think that option will go away, if it did, then the EU would probably 
> heavily fine which ever motherboard maker that does remove the option, then 
> force them to put it back.

*eventually*
Note how long it took them to deal with the Internet Exploder and Media Player 
problems - the sanctions when they eventually came in were ineffective (and 
just confusing to users) as things had already moved on.

MS could very easily "require" manufacturers to lock stuff down through dodgy 
"marketing incentives". By the time the EU got round to fixing things, the 
situation could very well have moved round to only "approved" Linux was usable 
on most hardware.
We already have a signed Grub, it's only one more step for the signed grub to 
only boot a signed kernel, ...

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

Re: [DNG] secure boot

2016-06-12 Thread Simon Hobson

Didier Kryn  wrote:

> The dealer will just be instructed to not sell it to people who claim they 
> will do anything else than using the pre-installed Windows.

Eventually yes.
But it will make their management aware of us for them to issue the instruction.

But bear in mind that a lot of the "sales" people at the big sheds will tell 
you it'll brew the tea and create world peace if it gets them one more sale 
towards their target.
OK, I exaggerate a bit - but if people ask them if it runs Linux, and 
management have told them to say no, then that means they've at least heard of 
it.

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

Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...

2016-06-12 Thread Simon Hobson

Edward Bartolo  wrote:

> I have been 'told' that any kernel can still be booted under UEFI
> Secure Boot.

For now, how long until that changes ?

> Refer to forums.debian.net thread:
> http://forums.debian.net/viewtopic.php?p=609579&sid=c65ab3dc5f980e0c1f79b7b7a5116511#p609579

And as pointed out there, it's hardly "drop in a disk and boot". For a very 
large percentage of users, it'll mean "Linux doesn't work" if the disk fails to 
boot.

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

Re: [DNG] LXC template for Devuan

2016-06-12 Thread Simon Walter

On 06/10/2016 10:39 PM, Greg Olsen wrote:

On 2016-06-10 08:59, Simon Walter wrote:
[snip]
 > > I will give the templates a go now.

I had some issues:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Over ten times repeated, but more importantly:

Simon, thanks for testing.

I think the locale just isn't setup yet at that early point.
Perhaps a Perl expert can opine?

Maybe we can diff that?

> ...

This might be a bit surprising but I actually wrote lxc-devuan with
*non-Devuan* OS's in mind. To not discourage people from running Devuan,
it automatically downloads and uses the Devuan keyring. Without that
capability it won't get past square one on a non-Devuan OS, and the user
is likely to mumble some not so nice things about Devuan. Something to
be avoided if at all possible.

It seems to be fine with the 'auto' sub domain maybe because the keys 
are registered for that domain name. Are you saying that those keys are 
pre-installed on the image? If that's the case, I think we should make 
two versions, that are based on the same source - an include or 
something. One to be used on Devuan, one to be used by other distros 
that want to run Devuan containers.

I also added a feature or two that other OS templates don't have, such
as the ability to pre-assign the MAC address. I have absolutely no idea
if that's of interest to anyone but me. But if it is, that's yet one
more reason for people to choose Devuan over something else.

Yes, I really like that. It is very useful.

Of course, the paths won't end up correct on all distros until a version
of it makes it upstream, and then back down again, and that could take
quite some time. Therefore a script can/should be written to help
install it.

wget or maybe curl? What's on a base install?

In the meantime, anyone with a mind to "clone" and use the template as
is (without a proper package or script to install it) will have to
adjust paths as needed to match their system.

On the other hand there's nothing written anywhere that says we have to
use the lxc-devuan that I wrote. Not that I want to give up on it, but
If yours is already working correctly on Devuan Beta, we can always put
it in a different branch and use that.  We'll just have to see how
things plays out.

I've made an account on git.devuan.org (user: smwltr) How do you want to 
do this? Shall I fork your repo and apply a patch and then send you a 
pull request? After a look maybe the solution will present itself. I 
guess the .conf files too.

Let see how it goes.

Cheers,

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

[DNG] Devuan on Android

2016-06-13 Thread Simon Walter


Hi all,

I want to report that I've installed Devuan on a "rooted" Android device 
using DebKit.


All I did was:
1. Change the package mirror to: auto.mirror.devuan.org/merged
2. After the debootstrap process is complete and under the chroot 
install the devuan-keyring package.


I tried to use some other apps like LilDebian, DebianKit, and 
LinuxDeploy, but for some reason they didn't work for installing Debian. 
So I didn't try Devuan.


It's nice to have Devuan on my portable computing device.

Thank you,

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

Re: [DNG] ..another new(?) step towards Debian systemd: linux-image-4.6.0-1[-rt]-amd-signed, with MSTF keys...

2016-06-13 Thread Simon Hobson

Edward Bartolo  wrote:

> But I still am convinced with a signed kernel one can still use it to
> boot any installed OS. My reasoning goes like this: once the signed
> kernel boots, it would be in control of the machine. A running kernel
> can be used to run any executable provided the latter is coded for the
> same machine architecture. So, the boot procedure would first consist
> of UEFI loading the signed kernel, the kernel then loads a bootloader
> like GRUB*.
> 
> What do you think?

Yes, it can be done. No it's not something your average user could do on his 
own.

What you point out is the weakness of signing code - if that code isn't itself 
"secure" then it defeats the point of signing anything.
So long term, not this year, probably not next year, but sometime ... expect 
some pressure to extend the signing. The first step will be signing of kernel 
binaries in distros, then some extra code in Grub to only load signed kernels - 
and only versions of Grub built that way will get signed. So now we've reached 
the point of only being able to use a Grub that will only load signed kernels. 
And only 'clean' kernel binaries will get signed - so no "non-approved" drivers.

And if that bit of wedge gets hammered in without too much pushback ... The 
next step will be to add kernel code to only run signed binaries - but it'll be 
OK for the likes of RH because you'll have no reason to run anything other than 
the binaries they supply for packages.

Yes, you can build a Grub that will load any kernel - but the EFI won't load it 
as it won't be signed.

And expect it to get harder to add your own sigs to EFI systems as well.

And all in the name of "security". Rrriiight.

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

Re: [DNG] LXC template for Devuan

2016-06-13 Thread Simon Walter

On 06/14/2016 09:26 AM, Greg Olsen wrote:

On 2016-06-13 01:28, Simon Walter wrote:
[snip]
 > > This might be a bit surprising but I actually wrote lxc-devuan with
 > > *non-Devuan* OS's in mind. To not discourage people from running
Devuan,
 > > it automatically downloads and uses the Devuan keyring. Without that
 > > capability it won't get past square one on a non-Devuan OS, and the
user
 > > is likely to mumble some not so nice things about Devuan. Something to
 > > be avoided if at all possible.
 >
 > It seems to be fine with the 'auto' sub domain maybe because the keys
 > are registered for that domain name. Are you saying that those keys are
 > pre-installed on the image? If that's the case, I think we should make
 > two versions, that are based on the same source - an include or
 > something. One to be used on Devuan, one to be used by other distros
 > that want to run Devuan containers.

The issue isn't the domain and there's no pre-installed image.  It's a
chicken and egg problem to bootstrap the keyring to validate the signed
packages.

Well, maybe I didn't say it correctly. Is there already a devuan-keyring 
package on the iso-image? If so, that would explain why it works fine 
when the "host" is a Devuan installation.

My personal opinion is that keys should not be automatically downloaded 
and installed. But I am a bit paranoid.

Assume install on a foreign OS.  The foreign OS probably won't have a
Devuan keyring. When running debootstrap, among the packages it will
download is the keyring package. When it goes to validate the download
(which includes the keyring package), it doesn't have a key to validate,
so it fails with "Release signed by unknown key".

Yes. So, perhaps we have one script maintained for the Devuan OS and 
another for non-Devaun OSes, and they have most things in common.

[snip]
 > I've made an account on git.devuan.org (user: smwltr) How do you want to
 > do this? Shall I fork your repo and apply a patch and then send you a
 > pull request? After a look maybe the solution will present itself. I
 > guess the .conf files too.

Hi Simon,

For now we can work it that way.

I just pushed an update that adds support for LXC <= 1.0.8.

The README is updated to use ./config-1.0.8 for LXC <= 1.0.8
The existing ./config directory is for LXC >= 1.1.0

It'll be great if you'll test again.

So if you've already forked, please fetch and rebase.

Nice. Sure thing. I will be testing it out soon.

Kind regards,

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

Re: [DNG] LXC template for Devuan

2016-06-14 Thread Simon Walter

Hi Greg,

I've read had a look and a test. Please see my ramblings below. I am in 
no hurry. So please take your time. ;)

On 06/14/2016 10:02 AM, Greg Olsen wrote:

On 2016-06-14 00:39, Simon Walter wrote:

 > Well, maybe I didn't say it correctly. Is there already a devuan-keyring
 > package on the iso-image?

It's a debootstrap install. There's no iso-image involved.

I think that maybe you read my email too fast. So I will try to be verbose.

I install Devuan on my hardware from an iso CD-ROM image file copied to 
a USB memory device.

Next I install LXC.

Next I modify the debian template lxc-debian - remove systemd stuff, 
rename a bunch a of things and change the mirror.

When I use that modified template to lxc-create a container, I don't 
need to download any keys.

I am guessing because devuan-keyring is already installed from the iso 
CD-ROM image on the initial installation on my hardware.

Does that sound like the reason? Am I missing something?

 > My personal opinion is that keys should not be automatically downloaded
 > and installed. But I am a bit paranoid.

I understand your reservations. However it does **not** trust the
keyring on the user system.

Does that mean that it does not trust the keyring on the host? Is there 
a good reason for that? I thought the template checks for 
/usr/share/keyrings/devuan-keyring.gpg on the host.

It simply downloads it, issues a message it
was downloaded, and then passes the keyring file to the debootstrap
command for it to use validating packages.  So it's completely safe.

It downloads a keyring from a server. Is it in anyway possible to hijack 
those connections and download a different keyring to validate different 
packages from a different server? It would be a great big coordinated 
attack, but is it impossible?

The template defaults to downloading and also to passing --no-check-gpg.

I would suggest making the default to check for the devuan key and fail 
with an error message saying that the key was not found and telling the 
user that there is an argument they can specify to have it downloaded. 
That is IMHO the rule of least surprise.

Forgive my criticisms and questioning. In a world where we have people 
planting questionable code into open source in order to create back 
doors, we should be able to answer to this kind of criticism - if only 
to aid ourselves (think rubber duck programming).

Now on to the latest test I made:

The locale is set early enough to not have those warnings spew all over 
the screen. Excellent.

More importantly, the errors about the config files are gone. I had a 
look at the differences, and it all seems reasonable.

Also I notice gcc-4.8-base is being removed towards the end. I am sure 
there is a good reason for this and I am interested to know.

About the random MAC address feature, I see a comment:
## If there is exactly one veth network entry,
## make sure it has an associated hwaddr.

How does veth get into the config file at this point? Should the user 
create the config file before creating the container? It seems like 
there are so many options on how one could create the network. However, 
if arguments were given for a few things:

lxc.network.type
lxc.network.link
lxc.network.ipv4
lxc.network.ipv6
gateway
network

Then a simple network could be set up by the template - both the LXC 
config and the network inside the container. Otherwise it doesn't seem 
to work "out of the box." More complex configurations would require 
editing the config file.

There are a few more things I wanted to discuss.

- "Less bare bones than from debootstrap, however dependencies are kept 
minimal."

- OpenDNS name resolvers are set.

- The random password is removed. (I would suggest that if a password 
argument is not given, a random one is set.)

These seem like they are useful. My criticism is not directly at any one 
of these ideas. I am thinking of the naive user who doesn't expect to 
find things set up this way.

Maybe we need a bare template and then one with all the nice options. Or 
maybe we need this template to install the bare minimum if no arguments 
are given, and then when certain arguments are passed, we get OpenDNS, 
the password we want, and the nice set of packages, etc. If the 
arguments are available, then at least the user has an vague idea, 
without reading the template, of what is possible and what the container 
will be set up like.

Because packages are removed after the root password is displayed, it 
gets pushed up the screen. It would be nice to have that as the last 
thing that is displayed.

If you want me to hack on any of this let me know.

Kind regards,

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

Re: [DNG] LXC template for Devuan

2016-06-14 Thread Simon Walter

On 06/15/2016 10:26 AM, Greg Olsen wrote:

On 2016-06-14 09:22, Simon Walter wrote:

 > I think that maybe you read my email too fast. So I will try to be
verbose.

Hi Simon,

If I misread then I apologize.

No need to!

...
 >
 > Also I notice gcc-4.8-base is being removed towards the end. I am sure
 > there is a good reason for this and I am interested to know.

I got that from the "Minimal Install Guide":
https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/Minimal-install-guide

See section entitled "Removing unwanted packages".

I will have a read.

...

 > How does veth get into the config file at this point? Should the user
 > create the config file before creating the container?

The stock default.conf from Jessie:
# cat /etc/lxc/default.conf.orig
lxc.network.type = empty
#

So the default for everyone regardless of the template used is "no"
network.

The coin drops. I see. That is what is going on.

...
My intent was not to teach how to use LXC. That's why the reference in
the README "LXC Documentation" section.

In hindsight I must admit, it will be better to show the default.conf
file, as was used to arrive at the result in Example 7.  I have another
tweak planned for the README, so I can add that to the list.

Nice. Thank you for explaining. I must admit, I didn't know that even 
file existed.

Yep.  A simple network could be set up "out of the box".

However I must first ask, what happened to your "rule of least surprise" ?

Yes, I stand by my suggestion that the default is minimal and everything 
else takes parameters. How does that contradict the rule of least 
surprise? If they are not specified, then no action is taken. By the way 
it's not *my* rule - just something I was taught similar to convention 
over configuration.

IMHO it's unfair to state it doesn't seem to work when the default use
case is, *no* network.

Being the default is *no* network, I think we have the responsibility to
also consider, the existing user base has good reason to expect no
communications can occur unless they explicitly change their default.conf.

Yes, please pardon my ignorance. Everything makes more sense in light of 
that file.

 > There are a few more things I wanted to discuss.
 >
 > - "Less bare bones than from debootstrap, however dependencies are kept
 > minimal."

Package inclusion and exclusion is indeed open to discussion/debate.

 > - OpenDNS name resolvers are set.

I thought about setting the IP's in variables with template options for
override purposes.

 > - The random password is removed. (I would suggest that if a password
 > argument is not given, a random one is set.)

New containers have root password = root, the same as lxc-debian provides.
I simply kept with that expectation, and that people should change the
root password.

Beyond that I haven't given much time/consideration.

What do all the other templates do with this?
Do we want to depart from the expectations admins may already have from
working with other templates?

Hmmm... I am not sure which version you are using. I see this in lxc-debian:

password="$(dd if=/dev/urandom bs=6 count=1 2> /dev/null | base64)"
echo "root:$password" | chroot $rootfs chpasswd
echo "Root password is '$password', please change !"

I know some of the other templates to use 'root' as the password. I have 
seen this criticized:

https://fedoraproject.org/wiki/LXC_Template_Security_Improvements

 > These seem like they are useful. My criticism is not directly at any one
 > of these ideas.

I don't take any of what you said as criticism. I think tossing around
ideas for improvement is a good thing.

OK. Good. I don't want to piss anyone off, and my social skills are not 
that smooth. So I worry.

I also see things as falling into a category:
1. Base functionality (priority, need it now)
2. Enhancements (nice to have)

I think the immediate focus should be to get the base functionality
correct, submit upstream, and make a package available.

I think what you have so far is most of the way there.

Work on enhancements can start anytime, including now if you're so
inclined. A typical way to handle enhancements is for each developer to
work in their own feature branch, for possible later inclusion in master
branch.

I am not familiar with gitlab. Does one join a project? Or should I 
create a new project? Or should I just hack locally and send a pull 
request? I am also wondering if some place on gitlab is better to 
discuss when I have a question for this project. Or right here on DNG? I 
don't want to start on adding things like some of those template 
parameters and then you've already done it. You seem pretty fast paced. 
I hope I can keep up!

Cheers,

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

Re: [DNG] Installer Devuan Jessie 1.0 fails

2016-06-15 Thread Simon Walter


On 06/15/2016 06:21 PM, emnin...@riseup.net wrote:
...


But if so: Shouldn't we investigate the installer? I mean, it's not
really user friendly to have an installer subject to that kind of
errors. And in my experience there are even other problems like the
overheating problem for amd graphics based machines, at least for some
of them. Or the fact, that the installer seems to not install the base
system it brings itself but seems to pull it from the mirrors.

Anyway, i'm well aware human ressources at Devuan are limited but the
installer should be worth a major consideration (?)


Since it is a universal OS. I would suggest we disable the graphical 
installer if it causing people to be put off. This may sound like 
heresy, but the text base installer is not minimal and it is fully 
functional.


I remember back in the days when Debian got the graphical installer, it 
was to be treated as BETA quality and if it didn't work, to use the text 
base.


I think the same applies here. Maybe we need to put a "use with caution" 
note. I think there was something like this on the original Debian 
graphical installer.


We are not so spoiled that we need to use a mouse for everything, are we?

Simon

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

Re: [DNG] cosmetic installer issues

2016-06-15 Thread Simon Walter




On 06/15/2016 08:16 PM, richard lucassen wrote:
...

1) Wishlist: a real PXE installer like Debian is providing. Just an
intrd.gz and a vmlinuz that will guide you through the install process.
No need for USB sticks or CD drives. Running a PXE installer together
with an apt-cacher-ng saves time (internal network speed) and saves
bandwidth usage for the Devuan community.


I think this would be really useful and professional.

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

Re: [DNG] Installer Devuan Jessie 1.0 fails

2016-06-15 Thread Simon Walter

On 06/15/2016 08:52 PM, emnin...@riseup.net wrote:

We are not so spoiled that we need to use a mouse for everything, are
we?

Simon

My problem (the failure while installing the base system) happens in
both, the graphical and the text mode installer.

I'd suspect there's something wrong with the underlying routines (as
also L. Nodden noted).

A working and solid keyboard only installer would be fine for me - and
i think for most users: It's all about being well explained, input
error tollerant and solid ...

(I could even live fine with an i3 based desktop, when it is well
done ;) ).

Aha! OK, then please disregard my comment. Because I thought the problem 
was only with the graphical installer. It seems it is something deeper.

Do you get the overheating/CPU problem? I think that could be debugged, 
but it would have to be done on the problem machine.

This is a good idea:

On 06/09/2016 05:28 AM, Paweł Cholewiński wrote:
> W dniu 07.06.2016 o 12:38, emnin...@riseup.net pisze:
>> (How can i debug the installation?)
>
> You could use this document:
> 
https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/Minimal-install-guide

>
> Use debootstrap --variant=minbase --include=nano,nvi,procps jessie
> /target http://auto.mirror.devuan.org/merged to add top command - You
> could use top on another console i.e. ctrl+alt+F3 after chroot to /target

Though maybe, while the installer is being perfected, there should be 
some tools for debugging available, rather than just busybox. Then 
people with problems can more easily help debug them and get the 
valuable info to the developers.

I installed from the netinstaller. So maybe on the full CD there is top 
and other tools. Anyone know what programs are on about the full CD?

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

Re: [DNG] LXC template for Devuan

2016-06-18 Thread Simon Walter


On 06/18/2016 10:31 AM, Greg Olsen wrote:
...


In the meantime, I added Simon Walter as a Developer for lxc-devuan.

Simon,

As a developer you can push directly to the main development branch. I
added a "draft" Contribution guide, and I'll be following the same
process myself as outlined.



Hi Greg,

Thanks for that. I will dig in soon. I am pretty busy at the day job. So 
much so that I'm in the office on the weekend.


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

Re: [DNG] How to stop udev from re-ordering devices

2016-06-20 Thread Simon Hobson

Rainer Weikusat  wrote:

> This is published here in the hope that it is useful for someting.
> 
> The basic design of udev is similar to that of a forking server: There's
> a parent process listening for uevents from the kernel on a netlink
> socket which passes these events to worker processes for actual
> processing. In case no idle worker process is found, a new one is
> forked, up to a configurable limit (=> udevd(8)).
> 
>   One could argue if using more than one worker process is
>   actually sensible considering that uevent processing happens
>   mostly during startup and isn't going to take much time,
>   especially as this is a text book example of the simple, obvious
>   design one shouldn't be using if good performance is to be
>   achieved: The process which read the uevent from the socket is
>   already running and the CPU executing it has all the data in its
>   cache and kicking this to another CPU is a waste: The process/
>   thread which received the event should process it and another
>   should be listening for more uevents while this is happening.
> 
> A less-than-desirable side-effect of this model is that uevents causing
> driver loads may end up loading the drivers in an order different from
> the one the uevents came in.

So it's suboptimal - perhaps why the systemd guys are so fond of it ! It also 
explains the "random" ordering that the systemd guys have "fixed" by making the 
names even more unfriendly.

Personally, I've always just edited /etc/udev/rules.d/70-persistent-net-rules* 
to give user-friendly names to my interfaces. Typically I use things like 
ethint, ethext, and so on - far better than trying to remember that eth0 is the 
internal port, eth1 is the outside, and so on.

* Don't know if that's "standard" or a Debian packaging thing.

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

Re: [DNG] LXC template for Devuan

2016-06-20 Thread Simon Walter


On 06/20/2016 07:28 AM, Greg Olsen wrote:

Hi Simon,

No rush. Unless I find some glaring bug, after a bit more testing I
intend to refocus on pushing upstream and what's needed to make
"lxc-devuan" packages for Jessie/Ascii/Ceres. It'll be the first .deb
package I've made completely from scratch (suggestions are welcome,
please).

Disable --no-check-gpg as the fallback?  No votes against this:
+1 Simon Walter
+1 Greg Olsen

So when convenient, I may go ahead and disable that.



Hi Greg,

I've added a branch called add-netconf, which you have probably seen.

I thought to just add one feature per branch so that review is easier. 
Let me know how you prefer to collaborate.


I was not sure about what style/standards we are using. However, the 
hashbang tells me bash. I looked at the other templates, and most use bash.


I wasn't sure if having all the settings in one argument or separate was 
better. The logic behind having them all in one argument is that all 
those are needed and cannot be derived from one another. So IP, netmask, 
and gateway are all in one comma separated argument. Maybe the parameter 
name should be "interface" or "ifconfig".


For my next edit, I would like to add the password parameter and if not 
specified would set a random one.


Then I was thinking of adding a parameter for MAC address, in case it 
should be explicitly set or not set or set to a random address.


I would appreciate your comments on that and of course on the netconf 
parameter and it's functionality.


One question, is --main-only the default? What is the default for the 
Devuan install? I am not sure, but I think the default is only main. If 
so, maybe we should reverse that argument to be something like 
--extra-repos. Or even --add-repos=main,non-free. That way the use can 
specify exactly the additional repositories on the command line.


I think that would be very useful for orchestration tools such as 
vagrant or cdist for example.


Cheers,

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

Re: [DNG] How to stop udev from re-ordering devices

Steve Litt  wrote:

> Of all the escapades of FreeDesktop.Org, managers of Lennart and the
> Redhats, these name thingies are some of the least onerous. I put a
> shellscript on the list a few months ago that delivers the wifi device
> name, and that script can be used in init scripts and the like.
> 
> I mean, by all means use it as a talking point, but if it's actually
> giving you trouble, look up my shellscript and use it.

It's not giving me trouble, I'm still on Wheezy, and I use udev rules to rename 
interfaces to meaningful names anyway.

But, I get the impression you only run "simple" systems. Once you start having 
firewalls (interface names in config file(s)), monitoring (interface names in 
config file(s)), data collection (interface names in config file(s)), ... it 
stops being something that you can "fix" with a script that will tell you what 
your interface is called today. Well, I suppose you can use the script to find 
out the name of the interface, and then expand that to hack all the other 
scripts/config file before the relevant services start ... hmm, isn't that the 
systemd way, create a mess and then create more mess to fix the problems caused 
by the first mess, and then ...

So yes, for a "simple" desktop/laptop environment it might not be an issue, but 
for non-simple stuff it does matter. For the sort of stuff I work with, the old 
udev way works just fine, and I mean just fine. Interfaces don't change very 
often, and when they do it's a quick and simple fix (edit 
70-persistent-net-rules) that only needs to be done in one place.

Or TL;DR - the "new" way sucks big time. In fixing a non-problem for several 
classes of user, they've created a much bigger problem for them.

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

Re: [DNG] [OT] [Re: Studying C as told. (For help)

2016-06-21 Thread Simon Walter




On 06/21/2016 05:28 PM, KatolaZ wrote:

On Tue, Jun 21, 2016 at 08:22:41AM +0200, Edward Bartolo wrote:

[cut]



I studied 'and' and 'or' boolean operators back when I studied Delphi
Pascal. I am embarrassed to have written such a stupid thing. It must
be due to the fact I wrote the email just before going to bed.

AND: requires ALL sub-expressions to be true to evaluate to true
i.e.   Q = A ^ B ^ C ^  D
 Q = 1 if and only if A = B = C =  D = 1

OR: only requires ONE sub-exression to be true to evaluate to true
i.e.   Q = A v B v C v  D
 Q = 1 if any Ai = 1

These properties are used by compilers to optimize on boolean
expression evaluation. If I remember well, there are also specific


Be careful, because conditional expressions in C are subject to
"short-circuiting", meaning that only the minimum number of
expressions sufficient to determine the value of a chain of && and ||
will be evaluated. In particular, a chain of || expressions will be
evaluated until there is one that evaluates to TRUE (!=0), while a
chain of && is evaluated until there is one of them which evaluates to
false (==0).



Isn't that how AND and OR work in most programming languages? Mind you, 
I am not familiar with that many.

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

Re: [DNG] [OT] [Re: Studying C as told. (For help)

KatolaZ  wrote:

> Be careful, because conditional expressions in C are subject to
> "short-circuiting", meaning that only the minimum number of
> expressions sufficient to determine the value of a chain of && and ||
> will be evaluated. In particular, a chain of || expressions will be
> evaluated until there is one that evaluates to TRUE (!=0), while a
> chain of && is evaluated until there is one of them which evaluates to
> false (==0).

Indeed, and that is the whole point behind using them in this way. I use them a 
fair bit in shell programming :
eg
> [  ] && something_to_do_if_test_matches

instead of
> if [  ]
>   then
> something_to_do_if_test_matches
> fi

or even on the command line as in :
> apt-get update && apt-get upgrade

There can be some situations that can trip you up, eg it might seem clever to 
do :
> some_command && another_command && echo "It worked !" || echo "Failed"


While a simple "echo" is unlikely to fail, if that step does fail (eg you are 
writing status to a file and there's a problem) then you could find both your 
'success' and 'fail' commands being run.

Used intelligently the && and || operators can both aid readability and improve 
performance - but equally can be used to obfuscate (either deliberately or 
accidentally).

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

Re: [DNG] [OT] [Re: Studying C as told. (For help)

2016-06-21 Thread Simon Walter


On 06/21/2016 06:09 PM, KatolaZ wrote:

On Tue, Jun 21, 2016 at 05:47:59PM +0900, Simon Walter wrote:

[cut]


Be careful, because conditional expressions in C are subject to
"short-circuiting", meaning that only the minimum number of
expressions sufficient to determine the value of a chain of && and ||
will be evaluated. In particular, a chain of || expressions will be
evaluated until there is one that evaluates to TRUE (!=0), while a
chain of && is evaluated until there is one of them which evaluates to
false (==0).



Isn't that how AND and OR work in most programming languages? Mind you, I am
not familiar with that many.


I didn't say that short-circuiting is a peculiarity of C :)


Aha! You certainly didn't. I was surprised that "non-short-circuiting" 
logical operators even existed.



I simply
said that short-circuiting is how C evaluates conditional
expressions. There are many cases (such as that of FORTRAN) in which
short-circuiting can be enabled or disabled at compile time, many
other cases (e.g. most of the dialects of BASIC and some other
esoteric languages) in which short-circuting does not exist, and many
more cases in which the language supports both eager and short-circuit
boolean operators (e.g., Java, Python, Perl, Ruby, etc.)

Boolean expressions in C are always subject to short-circuting.



Interesting. And here I was taking "short-circuiting" for granted. Well, 
you learn something new everyday. I will be sure to keep that in mind.


Can you to point me to those other operators that do not "short-circuit" 
in Java, Python, Perl, and Ruby? Are the operators different, or do you 
have to change the behaviour with a switch?


I am thinking we might use single ampersand or pipe (bitwise). Can we 
use bitwise operators as what would be a non-short-circuiting logical 
operator in C (or other languages)?


Very interesting!

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

Re: [DNG] [OT] [Re: Studying C as told. (For help)

Irrwahn  wrote:

> We could. But it is a kludge, and very bad style. 

Is this the right time to introduce ...


... wait for it ...



... you're probably not going to like it ...



... no spoilers ...



... it is "safe for work" ...



... unless your work is writing C code ...



http://www.ioccc.org

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

Re: [DNG] Studying C as told. (For help)

An interesting task would be to look at the various algorithms offered, work 
out how the compiler is likely to handle them when turning into code (or even 
look at the code generated), and then work out the efficiency of the different 
methods in terms of CPU cycles/character.
Of course, it's possible that different methods may come out best depending on 
the amount of whitespace to be removed.

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

Re: [DNG] How to stop udev from re-ordering devices

Steve Litt  wrote:

> Good point. Here in my house, I trust everyone with a physical console,
> so individual computers have simple or no firewalls.

I'm running servers where you have to assume everyone is out to get you.

> My Internet
> firewall is pFSense, and every once in a while I use OpenBSD/pf instead:
> I long ago gave up dealing with iptables.

I've done a little with iptables, but normally use Shorewall. The only systems 
I don't use Shorewall on are my Xen hosts where I run a small hand-crafted 
iptables setup. So each interface name appears there.

And there's the systems doing PPPoE - so interface name embedded in PPP config.

Then I have a fair bit of data collection (interface stats etc), mostly with 
shell scripts feeding into RRD databases (some of them Cacti, some outside of 
Cacti). So multiple mentions of interface names there.

And finally I have Nagios doing a load of monitoring. Some of that involves 
using arping (which needs to be told which interface to use) to monitor MAC-IP 
mappings to detect added/removed devices, and more importantly, duplicated 
addresses (2 devices set on same address).

All in all, it soon adds up. Just one more area where the freedesktop guys 
really don't have a 'kin clue how systems in the real world get used. Now some 
of these instances could use a "centrally provided" file by way of includes or 
similar (at least my custom scripts could) - but not all of these uses offers 
that facility, now do those that do support a single format.
All in all, the easiest way by far is to use stable and user(admin) set names 
for interfaces !

> AFAIK, those merry jesters
> from FreeDesktop.Org consider BSD not important enough to sabotage.

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

Re: [DNG] How to stop udev from re-ordering devices

Rainer Weikusat  wrote:

>> All in all, the easiest way by far is to use stable and user(admin)
>> set names for interfaces !
> 
> This is going to bite you in the posterior in case of canned OS
> installations intended to be usable on a wide range of differently
> configured 'servers' and not supposed to be maintained by anyhow
> 'UNIX(*)-savy' personnel, IOW, appliance-type installations. I need
> interface names which are stable, generally predictable (ie, if there
> are two interfaces they'll end up as eth0 and eth1), machine and
> NIC-independent and compatible with already existing software. The
> kernel naming scheme provides pretty much exactly what I
> need. Consequenstly, I'm determined to keep using it and software which
> gets in the way will be changed.

If you just use the default kernel naming scheme then you open yourself to the 
problem that udev was designed to solve - that of random device names. I do 
have personal experience of that - boot with a different disk (for maintenance) 
and eth0 & eth1 swap places (can't remember if it was "stable" when using just 
the main OS). And I've first hand experience of the "two disk controllers" 
problem where it really was random which disk was sda and which was sdb.
But once you go down the route of udev (or equivalent, eg vdev) and persistent 
rules, then "eth0" is just a subset of "admin set interface name".

I realise that in some cases, not using ethn will cause problems. I'll cross 
that bridge when I come to it. BTW ot all my systems have named interfaces - 
many do just have eth0 and eth1. But on a system with (IIRC) 7 interfaces, I'll 
take human readable over my memory every time !

> The nice thing about free software is that one may use it to solve real
> problems the developers disapprove of.

Yes, that's a good one.

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

Re: [DNG] Studying C as told. (For help)

Rainer Weikusat  wrote:

> Lastly, if the target system is Linux (as here), one can safely assume
> that EBCDIC won't be used.
> 
> None of this matter anyhow for solving algorithm exercises in an
> entry-level book about a programming language. 

On the other hand, it might just give a newbie to C (and others) some hints 
that might save their bacon (or that of others) later. When I first learned any 
programming, we too got to work on the basis that "letters are A-Z and a-z" - 
which as has been pointed out breaks quite convincingly once you step outside 
the "basic ASCII" character set. I would imagine that such hardcoded 
assumptions have been behind many a problem when internationalising code.

On 21 Jun 2016, at 18:50, Irrwahn  wrote:

>> An interesting task would be to look at the various algorithms offered, work 
>> out how the compiler is likely to handle them when turning into code (or 
>> even look at the code generated), and then work out the efficiency of the 
>> different methods in terms of CPU cycles/character.
>> Of course, it's possible that different methods may come out best depending 
>> on the amount of whitespace to be removed.
> 
> And results will differ depending on platform, toolchain, 
> compiler version, optimizer setting, and so on.
> 
> Another aspect beyond just runtime efficacy is this: 
> 
> Source code is written for humans, not machines! Clarity and 
> simplicity can help minimize code maintenance cost, and thus 
> easily outweigh some slight runtime penalty. Whoever has found 
> himself in a situation where he had to spend a considerable 
> amount of time trying to grok what some "clever", "manually 
> optimized" code is supposed to do, knows what I'm talking about.

I have no argument with that, or the rest of your response. However, I do think 
it is important for a programmer working in a high level language to have some 
concept of how changing (sometimes subtle) in code can impact on performance. I 
wasn't suggesting manually optimising code - but looking at how different 
algorithms and code arrangements impact how the end result runs.
Having no idea at all - or worse, not giving a s**t - leads to the scourge of 
"performance by throwing hardware at it".

I suspect we've all conversed with people who have approximately zero knowledge 
or interest in how "the greasy bits" of the machine ends up running their code. 
My first computer came with just 1k of RAM, and sockets for just 8k total. It's 
surprising what you can do with that !

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

Re: [DNG] How to stop udev from re-ordering devices

Rainer Weikusat  wrote:

>> If you just use the default kernel naming scheme then you open
>> yourself to the problem that udev was designed to solve - that of
>> random device names.
> 
> If you'll neither believe me nor the code wrt causes these 'random
> device names', may I try some kind of authority?
> 
>   7.4.3.7. Device naming order changes randomly after rebooting
> 
>   This is due to the fact that Udev, by design, handles uevents
>   and loads modules in parallel, and thus in an unpredictable
>   order.

And ?
Udev, at least on the Debian systems I'm used to, creates rules such that the 
interfaces will only be randomly named the first time they are encountered. 
After that, the naming is recorded so that each interface will have a 
completely stable name thereafter.

OK, I may be misunderstanding some of the internals, in particular "what" is 
responsible for the random module loading order - but I certainly recall it 
being a problem before udev came along. And after udev, I have somewhere where 
I can fix the names of things.

BTW - this is also an issue for video capture devices (TV tuners etc) as well 
as NICs. Comes up from time to time on the MythTV mailing list.

Rainer Weikusat  wrote:

>>Udev solved the problem of the stability of device names: once one
>> interface has been named eth0, the same interface will remain eth0 - 
>> without interference from the admin.
> 
> Unless the admin transfers the installation to another system. Assuming
> that everything used to work fine with eth0 - eth3, all hell will
> break lose because the sole four interfaces are now called eth4 - eth7.

But the point is, the admin can then, with one simple edit, return those to 
being eth0-3. That's just one step in transferring a system - along with 
partitioning disks, formatting filesystems, changing fstab if it's using ugly 
UUIDs, installing the bootloader, ...
Not only that, but you can decide which interface you want to have which name.

> The idea is already conceptually rotten as MAC addresses are usually
> programmable and may even be randomly generated.

True, MAC addresses are rubbish as an identifier - but they are there and for 
the sort of systems I'm used to, reasonably stable. Virtualisation changes that 
of course, but I set fixed MAC addresses for my guests for other reasons 
anyway. YMMV
IMO, using MAC address is the worst option, apart from all the others.

Now, if you as the admin decide to change your mAC address, then you can (at 
the same time) change the rule mapping interfaces. If anyone else is changing 
MAC addresses in your NICs then you have something of a problem ;-)

As an aside, when developing IPv6, the IETF group working on it agreed that MAC 
addresses are terrible - and excluded them from the packets. They've since been 
forced to add a new option to carry the MAC address simply because so many 
people have workflows reliant on them - and DUIDs (DHCP Unique ID) simply don't 
work in the real world, they are less stable than MAC addresses in many 
situations. Until hardware manufacturers assign DUIDs at manufacture time, and 
provide somewhere to store it, and all OSs use that storage, and ... then that 
won't change. I switch OSs, change HD, re-install OSs, boot off CD/DVD/USB 
stick/etc far far far more often than I ever change NICs.

>> But it does not solve the problem which Rainer adresses: to match the
>> device name with the visual labelling, ie the need for a predictable
>> matching between interface name and what is written on the box, so
>> that instructions to the user make sense.
> 
> That's something I specifically don't care about. Any mapping is good
> provided it's possible to write software such that it doesn't have to
> care about the hardware it's going to run on and that it's stable.
> 
> There's no way to predict external wiring from the bus geometry, only
> the hardware manufacturer knows about that.

Indeed. But when creating a system, at some point you will have to configure 
"stuff" such that it uses the port on the back that you want it to use. You can 
accept what the system gives you, and go and find every reference to it in your 
config and alter that - or you can do as I prefer and do that mapping exactly 
once and in exactly one place, giving each interface a name you decide on (even 
if that is eth0, eth1, ...).
And unless the new hardware is identical, something's going to change anyway - 
different chipset(s), different internal bus locations, different physical 
locations on back panel, physical labelling, ...

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

Re: [DNG] How to stop udev from re-ordering devices

I wrote:

>> Unless the admin transfers the installation to another system. Assuming
>> that everything used to work fine with eth0 - eth3, all hell will
>> break lose because the sole four interfaces are now called eth4 - eth7.
> 
> But the point is, the admin can then, with one simple edit, return those to 
> being eth0-3.

Just to add, coming back to a use-case you mentioned earlier.
If you are building an appliance, where you will be deploying to multiple 
hardware by imaging the disk and having it self-configure out of the box, then 
there are other options. In this situation, you'll have known hardware (or at 
least, a limited set of known configurations) - such as using physical bus 
location.
That's doable through udev rules without needing to have stupid and unwieldy 
device names.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] How to stop udev from re-ordering devices