Re: [DNG] connection manager as failing dns resolver?
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 > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] connection manager as failing dns resolver?
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 ___ 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)
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. Once I told it to remove Evolution (since I use Thunderbird), and it went on asking whether I wanted to keep each evolution plugin. 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)? 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. Best Ale -- ___ 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
On Thu, 29 Apr 2021 09:59:02 +0800
Brad Campbell via Dng wrote:
> G'day All,
>
> I've upgraded a staging server from Jessie to Beowulf and find a
> script in my initramfs is now broken, tracking it down it is a huge
> change in behaviour in the busybox version of dc and I can't find any
> reference to what I'm missing. Has anyone bumped up against this?
> I've tried this on both the arm and x64 versions and the behaviour is
> identical, so it's not an arm thing specifically.
>
> On jessie :
> brad@srv:~$ busybox dc
> 2
> 2
> add
> p
> 4
>
> On beowulf :
> root@rpi31:~# busybox dc
> 2
> 2
> add
> p
>
>
> What you can't see at the bottom of the last example is the rendering
> of the 0x02 character in the shell.
>
> The input processor also appears to have changed.
>
> brad@srv:~$ busybox dc
> 0x127
> p
> 295
>
> root@rpi31:~# busybox dc
> 0x127
> p
> 127
>
> Installed packages.
>
> root@rpi31:~# apt-cache showpkg busybox
> Package: busybox
> Versions:
> 1:1.30.1-4
> (/var/lib/apt/lists/deb.devuan.org_merged_dists_beowulf_main_binary-armhf_Packages)
> (/var/lib/dpkg/status) Description Language:
> File:
> /var/lib/apt/lists/deb.devuan.org_merged_dists_beowulf_main_binary-armhf_Packages
> MD5: b7707908219c331294f3f9e8d926a9dc Description Language: en
> File:
> /var/lib/apt/lists/deb.devuan.org_merged_dists_beowulf_main_i18n_Translation-en
>MD5: b7707908219c331294f3f9e8d926a9dc
>
>
> Reverse Depends:
>initramfs-tools-core,busybox 1:1.22.0-17~
>zfs-initramfs,busybox
>udhcpd,busybox 1:1.30.1
>udhcpc,busybox 1:1.30.1
>open-iscsi,busybox
>open-infrastructure-system-boot,busybox
>live-boot-initramfs-tools,busybox
>initramfs-tools-core,busybox 1:1.22.0-17~
>busybox-syslogd,busybox 1:1.30.1
>dropbear-initramfs,busybox
>cryptsetup-initramfs,busybox
>bootcd,busybox
>busybox-static,busybox
>busybox-static,busybox
> Dependencies:
> 1:1.30.1-4 - libc6 (2 2.28) busybox-static (0 (null)) initramfs-tools
> (3 0.99) busybox-static (0 (null)) Provides:
> 1:1.30.1-4 -
> Reverse Provides:
> busybox-static 1:1.30.1-4 (= )
>
>
> brad@srv:~$ apt-cache showpkg busybox
> Package: busybox
> Versions:
> 1:1.22.0-9+deb8u4 (/var/lib/dpkg/status)
> Description Language:
> File:
> /var/lib/apt/lists/archive.devuan.org_merged_dists_jessie_main_binary-amd64_Packages
>MD5: b7707908219c331294f3f9e8d926a9dc
> Description Language: en
> File:
> /var/lib/apt/lists/archive.devuan.org_merged_dists_jessie_main_i18n_Translation-en
>MD5: b7707908219c331294f3f9e8d926a9dc
>
> 1:1.22.0-9+deb8u1
> (/var/lib/apt/lists/archive.devuan.org_merged_dists_jessie_main_binary-amd64_Packages)
> Description Language:
> File:
> /var/lib/apt/lists/archive.devuan.org_merged_dists_jessie_main_binary-amd64_Packages
> MD5: b7707908219c331294f3f9e8d926a9dc Description Language: en
> File:
> /var/lib/apt/lists/archive.devuan.org_merged_dists_jessie_main_i18n_Translation-en
>MD5: b7707908219c331294f3f9e8d926a9dc
>
>
> Reverse Depends:
>udhcpd,busybox 1:1.22.0
>udhcpc,busybox 1:1.22.0
>live-boot-initramfs-tools,busybox
>initramfs-tools,busybox 1:1.01-3
>initramfs-tools,busybox 1:1.01-3
>cryptsetup,busybox
>busybox-syslogd,busybox 1:1.22.0
>busybox-static,busybox
>busybox-static,busybox
>bootcd,busybox
> Dependencies:
> 1:1.22.0-9+deb8u4 - libc6 (2 2.16) busybox-static (0 (null))
> initramfs-tools (3 0.99) busybox-static (0 (null)) 1:1.22.0-9+deb8u1
> - libc6 (2 2.16) busybox-static (0 (null)) initramfs-tools (3 0.99)
> busybox-static (0 (null)) Provides: 1:1.22.0-9+deb8u4 -
> 1:1.22.0-9+deb8u1 -
> Reverse Provides:
> busybox-static 1:1.22.0-9+deb8u1
>
> Am I doing something dumb?
>
> Regards,
> Brad
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
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.
Hope
Re: [DNG] Odd issue with busybox dc in beowulf
‐‐‐ Original Message ‐‐‐ On Thursday, April 29, 2021 2:59 AM, Brad Campbell via Dng wrote: > G'day All, > > I've upgraded a staging server from Jessie to Beowulf and find a script in my > initramfs is now broken, tracking it down it is a huge change in behaviour in > the busybox version of dc and I can't find any reference to what I'm missing. > Has anyone bumped up against this? I've tried this on both the arm and x64 > versions and the behaviour is identical, so it's not an arm thing > specifically. > > On jessie : > brad@srv:~$ busybox dc > 2 > 2 > add > p > 4 > > On beowulf : > root@rpi31:~# busybox dc > 2 > 2 > add > p > In case you did not try it, I observe the following on beowulf : ~$ busybox dc 2 2 + p 4 <--snip--> 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
