Re: [DNG] connection manager as failing dns resolver?

2021-04-30 Thread Xenguy via Dng
On Thursday, April 29, 2021 4:19:34 PM, d...@d404.nl wrote
> On 29-04-2021 22:11, Hendrik Boom wrote:
> > On Mon, Apr 26, 2021 at 12:53:53PM -0700, Rick Moen wrote:
> >> Quoting Hendrik Boom (hend...@topoi.pooq.com):
> >>> Looks as if the connection manager is taking over dns.
> >>>
> >>> Who knew?  And whom does it talk to?  Does it contain its own
> >>> recursive DNS resolver?  Or does it just pick up on the DHCP
> >>> signals it gets from elsewhere and take over?
> >> connman (which I don't use, and have only read about) does _not_
> >> appear to include a recursive nameserver.
> >> https://launchpad.net/connman
> >>
> >> The data you've posted so far that I've read in this thread (but I
> >> haven't caught up with the full thread, yet) seem bizarre, in
> >> suggesting that connman itself is hogging port 53 on localhost --
> >> which would definitely mean either it's handling any recursive
> >> requests or nothing is.
> >>
> >> I'd have been extremely surprised if any connection management
> >> utility had an integral recursive nameserver.  The latter are
> >> complicated projects, which is why there have been relatively few
> >> successful ones.
> > It would surprise me, too.
> >
> > My guess is that it gets the DHCP information and does nothing but
> > relay DNS requests to the DHCP-indicated nameserver.
> >
> > The problem I'm having is that sometimes the network anager seems to
> > fail in some unclear fashion, and when it does so, even if it
> > manages to re-establish connexions to the rest of the world, even
> > through the same server, it doesn't always seem to be able to do
> > name resolution afterward.  So DNS requests fail.
> >
> > It might re-establish taht connection through a different hardware
> > device on the laptop, by the way, such as switching between wired
> > and wifi.  Although all these connections lead to the same server
> > with the same IP number.
> >
> > To keep tings running, I hand-edit /etc/resolv.conf to point to an
> > easily remembered nameserver, such as 8.8.8.8.
> >
> > Of course that's clobbered next time I boot then machine.
> >
> > So I'm wondering -- can I stop the connectino manager from being
> > obnoxious, or if I replace it, what to I replace it with?
> >
> > -- hendrik
> >
> > P.S.  I seem to emember having a diffrent program setting up
> > connections long ago on another machine.  Might it have been called
> > network manager?  What such tools are available?
> >
> > If it weren't a single-user-at-a-time personal computer, having
> > network setup be a user instead of system responsibility would be
> > stupid.  As it is, when I boot up in a strange place I might like
> > some control as to what to connect to, so this stupid policy works
> > out OK.
> >
> > -- hendrik
> 
> I do have one stubborn laptop which has a similar behavior and to keep
> it going i have entered the dns in /etc/resolv.conf and made the file
> readonly. So far this works fine.
> 
> Grtz.
> 
> Nick

I'm not sure if this is the same issue, but will mention it FWIW.

I have been using wicd for some time, but when I heard that it may be
disappearing in our next release, I decided to try 'connman' (along with
'cmst' for the system tray component) as a replacement for wicd.

It seems to work fine, but I have not tested it much.  What I did happen
to notice though, was that connman seemed to import 2 nameserver IP's
automatically, and I *think* they originated from a configuration in my
router, which I no longer wish to use.  I was able to manually configure
connman to list the nameserver as 127.0.0.1, which is the configuration
I prefer, because I am running 'unbound', a local DNS resolver.  I have
not tested whether or not my manual configuration persists indefinitely,
as I would prefer it did.

As for all the various software that like to modify the /etc/resolv.conf
file contents, I have never understood the point of this behavior, and
found it very annoying from the very first time I noticed this, years
ago now.  Accordingly, I use 'chattr +i /etc/resolv.conf' to make the
file, and therefore my DNS settings, immutable.  This seems to work fine
for me.

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


[DNG] Flatpaks (was: Keeping unneeded packages of your system)

2021-04-30 Thread Hendrik Boom
On Fri, Apr 30, 2021 at 06:36:01PM +0900, Olaf Meeuwissen via Dng wrote:

> > And how about packages downloaded and installed outside of the apt
> > system (typically libreoffice, I'd guess)?
> 
> I try to stay away from those and if I really, really need them, they
> end up below /usr/local/.

So far, I have avoided them too.

But this does bring up the question:

What about the 'flatpak's that some projects are trying to foist on me?
What are they?
Do they install in the same space that's managed by apt?
Do they interferewith apt?
Is there a practical way to restrict them from operating with root
   privileges?
Or even to tell whether they want root privileges?

-- hendrik


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


Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

2021-04-30 Thread Arnt Karlsen
On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
<20210430143720.7311bc82@d44>:


> https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/
>  

..how it works:
https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/

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


[DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

2021-04-30 Thread Arnt Karlsen
Spam detection software, running on the system "tupac3.dyne.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Hi, ..are we|Devuan safe from this systemd backdoor malware,
   taking a lot of our .debs, kernels etc, from Debian? ..from El Reg: 
https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/
   

Content analysis details:   (6.1 points, 5.0 required)

 pts rule name  description
 -- --
 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in
bl.spamcop.net
  [Blocked - see ]
 3.6 RCVD_IN_SBL_CSSRBL: Received via a relay in Spamhaus SBL-CSS
[23.129.64.232 listed in zen.spamhaus.org]
 0.0 RCVD_IN_MSPIKE_H3  RBL: Good reputation (+3)
[46.30.212.3 listed in wl.mailspike.net]
-0.0 SPF_HELO_PASS  SPF: HELO matches SPF record
-0.1 DKIM_VALID_EF  Message has a valid DKIM or DK signature from
envelope-from domain
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
 0.1 DKIM_SIGNEDMessage has a DKIM or DK signature, not necessarily
valid
-0.1 DKIM_VALID_AU  Message has a valid DKIM or DK signature from
author's domain
 1.5 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[23.129.64.232 listed in dnsbl.sorbs.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust
[46.30.212.3 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_WL  Mailspike good senders


--- Begin Message ---
Hi,


..are we|Devuan safe from this systemd backdoor malware, taking a lot of
our .debs, kernels etc, from Debian?  

..from El Reg:
https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/

..it would be about as easy to sneak it in and make it run on our 
init systems, but also quite a bit easier to discover by competent
users and sysadmins.

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


Re: [DNG] Odd issue with busybox dc in beowulf

2021-04-30 Thread g4sra via Dng
<--snip-->

> Hi,
> by looking at the latest git code:
> 

> static const struct op operators[] ALIGN_PTR = {
> #if ENABLE_FEATURE_DC_LIBM
> {"^", power},
> // {"exp", power},
> // {"pow", power},
> #endif
> {"%", mod},
> // {"mod", mod},
> // logic ops are not standard, remove?
> {"and", and},
> {"or", or},
> {"not", not},
> {"xor", eor},
> {"+", add},
> // {"add", add},
> {"-", sub},
> // {"sub", sub},
> {"*", mul},
> // {"mul", mul},
> {"/", divide},
> // {"div", divide},
> {"p", print_no_pop},
> {"f", print_stack_no_pop},
> {"o", set_output_base},
> };
> 

> it seems to me that mod, add, sub, mul, div are disabled
> and only %, +, -, *, / are supported.
> Cannot say if simply uncommenting them restores
> the previous functionality, could be worth a try.
> Eventually if it works a patch for making them optional
> (CONFIG_DC_LONG_OPS or the like) could be sent
> to the list.


Perform a 'git blame' and then chase the relevant commit hasha potential 
for 'git revert'.




publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys


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


Re: [DNG] Keeping unneeded packages of your system (was Re: Advice to migrate from Beowulf to Chimaera)

2021-04-30 Thread Olaf Meeuwissen via Dng
Hi,

Alessandro Vesely via Dng writes:

> On Wed 28/Apr/2021 14:15:43 +0200 Olaf Meeuwissen via Dng wrote:
>> What I did
>> find somewhat weird is that it asked whether I wanted to keep all of the
>> xserver-xorg-video-* individually when I had already said `Y` to the
>> `task-desktop` package.  With `apt-mark` I just marked
>> `task-xfce-desktop` as manual and didn't have to make up my mind about
>> all the video drivers.
>
> Yes, I tried it and it asks lots of useless questions.

After I sent my post, I wondered whether that might just be caused by
them being alternatives.  So, I checked

  olaf@quark:~$ dpkg-query -W -f '${Depends}\n' task-xfce-desktop
  tasksel (= 3.54+devuan4), task-desktop, xfce4, slim | lightdm
  olaf@quark:~$ dpkg-query -W -f '${Depends}\n' task-desktop
  tasksel (= 3.54+devuan4), xorg, xserver-xorg-video-all, 
xserver-xorg-input-all, desktop-base
  olaf@quark:~$ dpkg-query -W -f '${Depends}\n' xserver-xorg-video-all
  xserver-xorg-video-amdgpu, xserver-xorg-video-ati, xserver-xorg-video-fbdev, 
xserver-xorg-video-nouveau, xserver-xorg-video-vesa, xserver-xorg-video-vmware

Nope, it's not an issue caused by alternatives.  All those video drivers
are hard dependencies of task-desktop.  Ho-hum!  But those aren't the
ones debfoster asked me about ... :thinking:

Upon closer inspection, there are a few Recommended: video drivers I
have installed courtesy of task-xfce-desktop as well and those were also
not asked about.  Then why is e.g. xserver-xorg-video-cirrus kept
installed as an automatic package by apt whereas debfoster asks me
whether I want it kept installed?

I think it has to do with all those video drivers having a

  Provides: xorg-driver-video

and the xserver-xorg package listing

  xserver-xorg-video-all | xorg-driver-video

in its Depends:.

So whereas apt appears to work "bottom-up", checking for a manually
installed package that has a dependency on each package (irrespective of
the fact that another package may already satisfy the dependency), it
looks like debfoster works "top-down" and remembers already satisfied
dependencies so it asks if you really want *multiple* dependency
satisfying alternatives installed.  Makes sense from a parsimony point
of view and I think I like that.  I've got this feeling that I may be
using a combination of apt-mark and debfoster in the future ... or
looking for options to make apt-mark take alternatives into account.

I should also make a note about checking out deborphan and cruft ...

> Once I told it to remove Evolution (since I use Thunderbird), and it went on
> asking whether I wanted to keep each evolution plugin.

Could it be that you have something else that depends on or recommends
something generic, say evolution-plugin, like I discovered for my Xorg
server's video (and input) drivers that triggered this behaviour?

I use neither Evolution nor Thunderbird so don't have a clue.

> Of a smart package, I'd have expected to look at what packages are configured
> for day to day usage.  There are several ways to do so, starting from the
> alternatives system, perhaps Firefox's handlers, recently accessed 
> executables,
> whatever.  And how about packages downloaded and installed outside of the apt
> system (typically libreoffice, I'd guess)?

I try to stay away from those and if I really, really need them, they
end up below /usr/local/.

For my personal needs, I sometimes want the latest versions of docker-ce
(instead of docker.io) or Kubernetes related packages.  These project's
run their own APT repositories, so I hook those in and apt-mark (and
debfoster for that matter) should be fine.

> What I really missed is a percent indicator.  How many questions are there
> ahead?  I terminated with 'q'.  Possibly, the only package it helped to remove
> is debfoster itself.

You could have started out with `debfoster -q` :-)
Check the manual page.  There appear to be quite a few options to help
one get started with a decent `keepers` file but it make take a few
iterations, just as I did using apt-mark.  I guess there's no silver
bullet here either ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng