Re: [DNG] Devuan ASCII 2.0.0 Beta released

[Patrick Meade]

On Wed, 2018-02-14 at 20:07 -0500, Fungal-net wrote:
> Because as per a couple of hours ago it seems as I have been exposed
> to this amprolla3 for 4-5 months now, without knowing, and although I
> run about the same stuff on a test debian isntallations, pkgs there
> rain down to the level of about 20-30/day, while ascii has been
> pretty inactive in terms of upgrades.  So what exactly is merged with
> devuan?

Hi Fungus,

Instead of asking, I think you should just point the browser of your
choice at the public repository:

http://pkgmaster.devuan.org/

Here you can browse everything served up by pkgmaster. You might want
to start with the /devuan and /merged directories.

Next, you can do something like:

curl -v http://pkgmaster.devuan.org/merged/dists/

And follow that up with:

torsocks curl -v http://devuanfwojg73k6r.onion/merged/dists/

In both cases, you should get the same content. The only exception
(that I'm aware) would be the pkgmaster rewrites for Debian hosted
packages. That is, if Devuan didn't have to alter a package because we
didn't need to, then we allow Debian to provide it.

So, for example, when I curl this package:

curl -v http://pkgmaster.devuan.org/merged/pool/DEBIAN-SECURITY/updates
/main/a/apache2/apache2_2.4.10-10+deb8u11_amd64.deb

I end up with this as the redirect:

< Location: http://deb.debian.org/debian-security/pool/updates/main/a/a
pache2/apache2_2.4.10-10+deb8u11_amd64.deb

But, if I curl through torsocks:

torsocks curl -v http://devuanfwojg73k6r.onion/merged/pool/DEBIAN-SECUR
ITY/updates/main/a/apache2/apache2_2.4.10-10+deb8u11_amd64.deb

I end up with a tor redirect:

< Location: http://sgvtcaew4bxjd7ln.onion/debian-security/pool/updates/
main/a/apache2/apache2_2.4.10-10+deb8u11_amd64.deb

Truly, I think KatolaZ can write e-mail until his fingers fall off and
you will not believe him. However, the above should be enough to get
started in conducting your own experiments. You don't have to believe
or trust me, KatolaZ, or anybody else. You are a mature person who can
can think for himself.

AND .. if you do find something odd/wrong, you'll have the commands to
give everybody to prove that you are right. This may have the side-
effect of allowing us to find and fix any problems as well.

Good luck!

Best,
Patrick

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

[DNG] Countering trusting trust (Was: forensics on systemd or journald logs)

[Patrick Meade]

On 11/23/2017 05:28 AM, Arnt Karlsen wrote:

..aye.  And then we have the good old Ken Thompson style compiler
hacks and 33 years of water under the bridge to come up with even
better hacks...


David Wheeler taught us how to counter Ken Thompson's Trusting Trust 
attack 8 years ago.


https://www.dwheeler.com/trusting-trust/

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

Re: [DNG] I found a new reason to dislike debian...

[Patrick Meade]

On 11/19/2017 10:01 PM, zap wrote:

there are dongle usbs whose firmware has been made free software, and I
cannot use this firmware from devuan, because some arrogant debian devs
were too lazy to remove the non-free package and add the free package.
so annoying.


Will you provide a link to this discussion, please?

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

Re: [DNG] Please provide systemd-free libreswan package

[Patrick Meade]

On 11/15/2017 08:30 AM, Sam Protsenko wrote:

Can you please provide libreswan package with sysvinit integration in Devuan?

Can someone please look into it?

P.S. Not sure that feature requests belong here, so if I'm wrong about
this, please point me out to correct place.

[1] https://packages.debian.org/search?keywords=libreswan
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855653
[3] https://anonscm.debian.org/git/collab-maint/libreswan.git/tree/debian/TODO
[4] https://github.com/libreswan/libreswan


Hi Sam,

Thank you for bringing this package to our attention. Good catch! I'll 
have a look at it later today when I get a chance.


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

Re: [DNG] Clear communication (Was: Debian testing drop redis)

[Patrick Meade]

On 10/28/2017 02:06 AM, John Hughes wrote:
While keeping your eyes peeled is obviously a good thing please remember 
the downsides of crying wolf when the wolf isn't there.


Clear communication is also a good thing. Perhaps the words

"[D]rops the Debian-specific support for ... in favour of using systemd"

were not the best choice of words to summarize something that was

"not a sysvinit-specific change"

or to communicate that

"this change is completely initsystem agnostic".

In fact, the change itself was actually fine, but a summary like "in 
favour of using systemd" will provoke a strong negative reaction on DNG 
because those words don't mean "initsystem agnostic" to most DNG readers.


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

Re: [DNG] Chris Lamb = Good Maintainer (Was: Debian testing drop redis)

[Patrick Meade]

On 10/26/2017 09:36 AM, John Hughes wrote:
Frankly it seems that some people have been rather fast to assume bad 
faith and very few people who commented either knew what they were 
talking about or made the slightest effort to actually understand what 
Chris Lamb had done.


I opened a pull request with Chris Lamb to discuss reverting his changes 
to the sysvinit scripts in redis-server and redis-sentinel.


We agreed that the functionality is obscure, affected users may be very 
hard to find, and any users who are affected can be helped with a 
reasonable amount of effort. I closed my pull request until such time as 
we discover a user who needs our help. (Note: Chris is willing to help 
with sysvinit users too.)


Having investigated the technical issues, discussed it with a very 
reasonable maintainer, and come to a reasonable conclusion, I think we 
can call this good.


Sorry for the trouble Chris, and thank you for your hard work and 
continued support of both the Debian and Devuan communities.


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

Re: [DNG] Debian testing drop redis non systemd

[Patrick Meade]

On 10/23/2017 09:19 AM, John Hughes wrote:

On 23/10/17 15:59, Patrick Meade wrote:
As John Hughes said, this isn't quite as bad as we originally thought. 
We can still run redis-server with the Debian provided sysvinit 
script, and Debian isn't throwing away upstream files for no reason.


Also note that the upstream init script example doesn't support the 
Debian hook scripts.  Perhaps upstream don't think that's useful 
functionality?


However, it's not all sunshine and flowers either. The daemon state 
change hooks are removed in the latest Debian package. If someone had 
a script that pre-loaded data into the redis cache on daemon start, or 
fired off a backup of the persistent store on daemon stop, these 
scripts would no longer be called when redis goes up/down.


Given that there is no documentation for these scripts other than the 
Debian changelog is anyone using them?


These are two good questions, but unfortunately it seems run-parts is a 
common idiom in Debian that dates back to 1994. Even if the redis 
feature was not well documented, it is not unrealistic to think that a 
system administrator could have gone to /etc/redis, saw the directories, 
and understood by the name of the directory what kind of script goes 
there, and what it would do.


So we have two groups of systems here.

Group A: Systems that never used the init script hooks in redis.

Group B: Systems that made use of the init script hooks in redis.

Group A pretty obviously doesn't give a rip either way. They never used 
the functionality, so they don't miss it now that it's gone. If we bring 
it back, they almost certainly won't care that it came back. If we leave 
it gone, they almost certainly won't care that it's still gone. Any 
action on our part neither helps nor harms the Group A folks. So, we set 
them aside.


The Group B folks will notice their system break once they upgrade. If 
we bring the functionality back, they will be happy that their system 
still works (sunny day). If we leave it gone, they will be unhappy that 
their system is broken (rainy day). The sunny day case requires nothing 
further, so we set it aside.


The rainy day case has two possible paths; try to fix the system or let 
it stay broken. The path chosen by the user will depend on their goals. 
The case where they let it stay broken requires nothing further, so we 
set it aside. The case where they try to fix it gets interesting.


If they are on Debian proper, the advice given will likely to be update 
the systemd unit to point to their scripts. systemd will run their 
scripts and they will be happy again. Since this case requires nothing 
further, we set it aside.


However, if they are on Devuan, there is no systemd. And without 
restoring the old functionality or providing new functionality, our 
answer will be an empty one: "Debian upstream broke it. Sorry." And our 
poor system administrator goes away empty handed, and maybe starts 
looking for a new distro.


Finally then, on the only path where our actions actually matter, we 
have two choices:


1. Restore the functionality, so that everybody including Devuan users, win.

2. Neglect the functionality, and let everybody except Devuan users, win.

Only the first option is acceptable to me, so what needs to be done is 
also clear to me. I'm hoping that the Debian maintainer will be willing 
to revert this change, as that would be the easiest way for everybody to 
win. If not, well... there is some work ahead.


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

Re: [DNG] Debian testing drop redis non systemd

[Patrick Meade]

On 10/23/2017 04:10 AM, John Hughes wrote:

On 21/10/17 01:53, Patrick Meade wrote:


That text is not from the Debian changelog, but rather from debian/NEWS.


Ah, didn't notice that.  Always trust the code before the doc.

Still don't understand why it says "in favour of systemd's ... commands" 
when the patch does no such thing.


The only way I can understand it is as a poorly phrased way of saying 
"we're dropping this feature, systemd users could do something to work 
around that".  I guess he could have added suggestions for sysvinit and 
upstart users as well.  But in no way does this patch somehow remove 
sysvinit support for redis in Debian.




The GitHub commit is here:

https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-e2b5949461a30128734d213f0ead1565 



I must admit that I'm still learning the ropes with respect to Debian 
packaging. Could you explain this diff of debian/redis-server.init to me?




What's to explain?  It "drops the Debian-specific support for the 
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories" 
by removing the calls to run-parts.


--

tl;dr:
- Neither redis-server 3.2.6 nor redis-server 4.0.2 provide the upstream 
sysvinit examples
- redis-server 4.0.2 still has support for sysvinit commands in 
etc/init.d/redis-server

- redis-server 4.0.2 removes the pre/post up/down hooks for sysvinit
- hopefully, we can ask Debian maintainer to revert, if not, we have 
work ahead


--

Okay, I got a chance to dig into redis-server a little bit this morning. 
I unpacked the stretch version of the package (3.2.6), and the 
buster/sid version of the package (4.0.2):


http://http.us.debian.org/debian/pool/main/r/redis/redis-server_3.2.6-1_amd64.deb

http://http.us.debian.org/debian/pool/main/r/redis/redis-server_4.0.2-3_amd64.deb

ar x package.deb
tar xvf data.tar.xz
fgrep -R "init.d" *

I then looked into the files identified by the fgrep command.


redis-server 3.2.6 reports:

etc/init.d/redis-server:	echo "Usage: /etc/init.d/$NAME 
{start|stop|restart|force-reload|status}" >&2
etc/redis/redis-server.post-up.d/00_example:# "/etc/init.d/redis-server 
start" does not result in unintended consequences.
etc/redis/redis-server.pre-up.d/00_example:# "/etc/init.d/redis-server 
start" does not result in unintended consequences.
etc/redis/redis-server.post-down.d/00_example:# 
"/etc/init.d/redis-server start" does not result in unintended consequences.
etc/redis/redis-server.pre-down.d/00_example:# "/etc/init.d/redis-server 
start" does not result in unintended consequences.



redis-server 4.0.2 reports:

etc/init.d/redis-server:	echo "Usage: /etc/init.d/$NAME 
{start|stop|restart|force-reload|status}" >&2



I checked etc/init.d/redis-server against the upstream sysvinit examples:

https://github.com/antirez/redis/blob/unstable/utils/redis_init_script

https://github.com/antirez/redis/blob/unstable/utils/redis_init_script.tpl

The file provided upstream is an example script to start/stop in the 
sysvinit style. In Debian, this file is neither included nor used. 
Debian has its own custom script that relies on /sbin/start-stop-daemon 
to manage daemon state.



The next task was to figure out what the changes to 
etc/init.d/redis-server were doing. The Run_parts function and calls to 
it are removed from the Debian script. This means the pre/post up/down 
hook calls are removed when the daemon changes state.


The other files etc/redis/redis-server.{NEW_STATE}.d/00_example are just 
empty stubs that give advice on how hook scripts should be written. 
redis-server 4.0.2 removes these, because the pre/post up/down hooks are 
removed, so the examples would advertise functionality that doesn't 
exist any more.



Final takeaways:

- redis-server 4.0.2 still works with sysvinit; you can start/stop the 
redis service per normal with the script that still exists in 4.0.2


- redis-server 4.0.2 did NOT remove upstream redis sysvinit scripts. 
Upstream DOES provide an example script, but Debian DOES NOT include or 
use that script. Debian has its own script.


- redis-server 4.0.2 support for sysvinit is LESS FUNCTIONAL than 
redis-server 3.2.6; in particular, with 3.2.6, you can write pre/post 
up/down hook scripts that get called by the sysvinit system. In 4.0.2 
these scripts (if present) would be non-functional in the sysvinit system.


- The text from debian/NEWS, amended by the Debian maintainer in a later 
commit, reads:


This version drops the Debian-specific support for the 
/etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d directories in 
favour of using systemd's ExecStartPre, ExecStartPost, ExecStopPre, 
ExecStopPost commands.


The meaning of this is: "We're dropping calls to the sysvinit hook 
scripts. systemd already runs hook scripts via ExecStartPre, 
ExecStartPost, ExecStopPre, E

Re: [DNG] Debian testing drop redis non systemd

[Patrick Meade]

On 10/20/2017 10:22 AM, John Hughes wrote:

On 20/10/17 16:37, Antony Stone wrote:
However, Bardot Jérôme's original posting in this thread, quoting 
Chris Lamb

 Wed, 11 Oct 2017 22:55:00 -0400 said:

"This version drops the Debian-specific support for the
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories in
favour of using systemd's ExecStartPre, ExecStartPost, ExecStopPre,
ExecStopPost commands."

So, yes, what's been dropped is Debian-specific, but shouldn't we 
still be

concerned about the "in favour of systemd's ... commands"?


That's not what the Debian changelog says:


That text is not from the Debian changelog, but rather from debian/NEWS.
The GitHub commit is here:

https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-e2b5949461a30128734d213f0ead1565


In the buster/sid version (4:4.0.2-3) there is no code that I can find 
to run the {pre,post}-{up,down} scripts in sysvinit *or* systemd.


As version 4:4.0.2-3 is the version that "drops the Debian-specific 
support for the 
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories", 
it would be rather surprising if you did find those scripts.


I must admit that I'm still learning the ropes with respect to Debian 
packaging. Could you explain this diff of debian/redis-server.init to me?


https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-9e388da7cd119765989cc22d2bc07e5c

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

Re: [DNG] Caching leads to unresponsiveness

[Patrick Meade]

On 08/11/2017 10:43 AM, Joachim Fahrner wrote:
Linux uses all available more for caching of filesystems. When copying 
large files to slow network filesystems (nfs, smb, sshfs, davfs) it 
takes a long time until such allocated memory becomes free. When these 
network filesystems saturate memory linux becomes very unresponsive. It 
can take minutes to start applications.


Is there a way to limit memory usage of network filesystems?


I'm not sure if there is a way to limit cache usage by network 
filesystems specifically. The best resource I've seen on Linux using 
memory to cache filesystems is here:


http://www.linuxatemyram.com/index.html

If the cache truly is conflicting with your applications, the notes at 
the bottom of this page about /proc/sys/vm/swappiness may help:


http://www.linuxatemyram.com/play.html

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

Re: [DNG] A problem with a license

[Patrick Meade]

On 07/05/2017 10:46 AM, Ivan J. wrote:

That clause itself is not a big problem, but IMHO it should rather be
moved to the README file or something similar rather than the license
itself where it actually *is* putting restrictions and in the case of
FSF would not be considered free software.


It seems that you got your wish.

https://git.devuan.org/DPA/sd_journal_shim/commit/51455a60b824cf0a383f6a456c90c9e8b55df967

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

Re: [DNG] We need to speak up

[Patrick Meade]

On 03/14/2017 08:37 PM, Steve Litt wrote:

We have our quiet sans-systemd corners, and right now they're
comfortable, but remember that the Freedesktop/Redhat/SystemdCabal
consortium has the goal of eliminating systemd as a choice, and they
still have the power to take our init systems away from us, as a
practical matter, so we still need to tell the truth to bullshit like
that on the Debian-User list right now. Obviously there's a technical
component to software choice, but forget at your peril that there's
also a political component.


To paraphase: The more Debian tightens its grip on systemd, the more 
users will slip through their fingers.


Those users just need to know where to go. A simple informative post (a 
sign post) to the thread will accomplish that.



"Devuan (https://devuan.org/) is a fork of Debian that removes hard 
dependencies on init systems, ensuring the user is always free to choose 
the one they want. If this sounds like what you want, please stop by and 
introduce yourself."



We'll be happy to take the init freedom refugees, and Debian will be 
glad to be rid of the anti-systemd whiners they don't want to serve. 
It's always nice when things work out win-win like this.


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

Re: [DNG] Networking on installation

[Patrick Meade]

On 12/07/2016 11:23 AM, Steve Litt wrote:

* Because most wifi software sucks, I suggest Devuan roll its own CLI
  software, for the installation, that iwlist wlan0 scanning lists the
  access points, takes the ssid and password, and then appends the
  result of wpa_passphrase to the bottom
  of /etc/wpa_supplicant/wpa_supplicant.conf. In my experience this is
  the most reliable way to get wifi running for a given access point.


On 12/05/2016 12:55 PM, Steve Litt wrote:
> Wifi is always problematic. Always. NetworkManager, Wicd, and even the
> wpa_* all seem to fail at just the wrong time. If I were Devuan, I'd
> create a wifi module that:
>
> 1) Displays the wifi signals in signal strength order
>
> 2) Asks which you want, THAT YOU HAVE A PASSWORD FOR!!!
>
> 3) Ask for the password twice,verify they match
>
> 4) Ask for default router
>a) With very helpful prompts and help
>
> 5) Ask if they'd like default dns  and 8844
>a) If not, suggest the default router
>
> 6) Run acquired passphrase through wpa_passphrase >> wpa_supplicant.conf
>
> 7) By hook or by crook, get a DHCP lease
>a) If necessary, put DHCP server on this computer
>
> 8) Verify lookup of devuan.org
>a) If not, run some intelligent diagnostic software

Is anybody working on this yet? If not, I might give it a shot this 
weekend. Steve, your vision for this is a subcomponent of the 
devuan-installer project, right?


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