Re: libdbi-perl broken?
On Tue, Aug 30, 2022 at 08:16:12PM -0700, Porter Smith wrote: > Jeremy, > > Have you tried to completely wipe the hard drive that your using in the > machine mentioned in the post. This of course would intail a through backup > of all important data sets. > > To nuke your stove I would like to recommend dban. What? -- t signature.asc Description: PGP signature
Re: libdbi-perl broken?
On 31/8/22 11:11 am, Greg Wooledge wrote: apt-cache policy libdbi-perl perlapi-5.28.1 On Debian 11, libdbi-perl should depend on perlapi-5.32.0 not perlapi-5.28.1 so I suspect you've got the wrong libdbi-perl somehow. It would also help if you showed the full error message, instead of only a part of the error message. I resolved the problem by changing my sources.list to use the debian original rather than my regional mirror. This works: cat sources.list deb http://deb.debian.org/debian/ bullseye main deb-src http://deb.debian.org/debian/ bullseye main deb http://security.debian.org/debian-security bullseye-security main contrib deb-src http://security.debian.org/debian-security bullseye-security main contrib deb http://deb.debian.org/debian/ bullseye-updates main contrib deb-src http://deb.debian.org/debian/ bullseye-updates main contrib -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: libdbi-perl broken?
Jeremy, Have you tried to completely wipe the hard drive that your using in the machine mentioned in the post. This of course would intail a through backup of all important data sets. To nuke your stove I would like to recommend dban. On August 30, 2022 8:03:29 PM PDT, Jeremy Ardley wrote: >I am install a VM for a LEMP server using the latest ISO >debian-11.4.0-amd64-DVD-1.iso > >The problem is installing mariadb (after installing nginx and php-fpm and >doing apt update and apt upgrade) > >sudo apt install default-mysql-server > >... > >The following packages have unmet dependencies: > libdbi-perl : Depends: perlapi-5.28.1 > >similarly > >sudo apt install mariadb-server > >and > >sudo apt install libdbi-perl > >Checking on the error message on the internet, there is nothing recent > >Any suggestions? > > >As an aside, I notice the latest debian install is very minimalist. It doesn't >even install sudo. Is this a change from previously? Or have I become >accustomed to armbian etc? > >-- >Jeremy >
Re: libdbi-perl broken?
On Wed, Aug 31, 2022 at 11:03:29AM +0800, Jeremy Ardley wrote: > I am install a VM for a LEMP server using the latest ISO > debian-11.4.0-amd64-DVD-1.iso > The following packages have unmet dependencies: > libdbi-perl : Depends: perlapi-5.28.1 apt-cache policy libdbi-perl perlapi-5.28.1 On Debian 11, libdbi-perl should depend on perlapi-5.32.0 not perlapi-5.28.1 so I suspect you've got the wrong libdbi-perl somehow. It would also help if you showed the full error message, instead of only a part of the error message. > As an aside, I notice the latest debian install is very minimalist. It > doesn't even install sudo. Is this a change from previously? Or have I > become accustomed to armbian etc? Debian installs sudo during the installation if and only if you leave the root password blank. If you want sudo, you can simply install it. Having a root password set allows you to boot into single-user mode, so I would advise setting one, even if you rarely use it.
libdbi-perl broken?
I am install a VM for a LEMP server using the latest ISO debian-11.4.0-amd64-DVD-1.iso The problem is installing mariadb (after installing nginx and php-fpm and doing apt update and apt upgrade) sudo apt install default-mysql-server ... The following packages have unmet dependencies: libdbi-perl : Depends: perlapi-5.28.1 similarly sudo apt install mariadb-server and sudo apt install libdbi-perl Checking on the error message on the internet, there is nothing recent Any suggestions? As an aside, I notice the latest debian install is very minimalist. It doesn't even install sudo. Is this a change from previously? Or have I become accustomed to armbian etc? -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: chromium: "Your browser is managed"
On 2022-08-30 at 20:18, Jeremy Ardley wrote: > On 31/8/22 7:36 am, Jon Leonard wrote: > >> On Tue, Aug 30, 2022 at 04:27:09PM -0700, L L wrote: >> >>> I'm on bullseye, and installed chromium from the bullseye repos. >>> In Chromium I get the message that the browser is "managed by >>> your organization." I didn't do any special setup for work or >>> school. Is the management part of the Debian packaging, or is >>> something sketch going on? >> >> There's malware that does that. The feature is usually for things >> like company-wide security policy, but if you're not expecting it, >> it's almost certainly malware. It's presumably trying to spy on >> you or serve you ads or some such.-- > > The managed message is not malware. It's just part of the standard > configuration in Debian. > > If it annoys you, remove the files in /etc/opt/chrome/policies I have no such directory (not even /etc/opt/chrome, or for that matter /etc/opt/chromium), but I do have this message. I do have /etc/chromium/, which has a policies/ subdirectory; the only thing in that latter is a recommended/ subdirectory, and the only thing in that is a file named duckduckgo.json. dlocate tells me that that file was installed by the chromium package itself. /usr/share/doc/chromium/changelog.Debian.gz tells me that this was put in place in version 104.0.5112.101-1 (the latest as of this writing), in response to bug #956012. As it happens, you can look up information about the policies in effect (though not, at least as far as I can tell at a glance, the paths to the files they're coming from) by entering 'chrome://policy' into the Chrome address bar. On my system, the page that comes up from that shows a variety of search-related configuration settings, several of which reference DuckDuckGo. So that's almost certainly coming from that recommended-policy file, although the details of "recommended" vs. "enabled" and what you're supposed to do if you want to disable it (and avoid having it come back on a future package update) I'm not sure. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: networking.service: start operation timed out [SOLVED]
On Wed, Aug 31, 2022 at 08:49:29AM +0800, Jeremy Ardley wrote: > One of my problems with systemd is the that name resolution is by default > done by resolved. Not in Debian. unicorn:~$ systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; ve> Active: inactive (dead) Docs: man:systemd-resolved.service(8) man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-> https://www.freedesktop.org/wiki/Software/systemd/writing-resolver> That's the Debian default. I didn't have to disable it, although I certainly *would* have, had the default been otherwise.
Re: networking.service: start operation timed out [SOLVED]
On 30/8/22 9:56 am, Ross Boylan wrote: Now everything just works. Thanks again to everyone. There are probably some general lessons, though I'm not sure what they are. Clearly the systemd semantics tripped me up; it's kind of an odd beast. I understand one of its major goals was to allow startup to proceed in parallel, which is pretty asynchronous. But it has to assure that certain things happen in a certain order, which results in some things being synchronous and blocking. I'm surprised that a tool intended for use from the command line (systemctl) is blocking. Ross One of my problems with systemd is the that name resolution is by default done by resolved. If resolved was bug free that might be O.K. but it's not - and in a production environment it's not a safe option. A result of the use of resolved is the start-up and dependency logic. If you start doing things outside of the plan, you run into all sorts of problems. I use bind9 on my various machines and have had to go to some lengths to take resolved out of the equation. On a similar but different topic. I have a router that connects to an upstream server and also runs haproxy. The upstream connection uses DHCP and IPv6 solicitation. The problem is haproxy fails to start when the upstream connection is not established and configured quickly enough. What would be very helpful is a systemd way to start haproxy when the network is established 'as configured'. So far all I can do is run a cron job to see if haproxy is running and if not, try and restart it. There has to be a better way. -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: chromium: "Your browser is managed"
On 31/8/22 7:36 am, Jon Leonard wrote:
On Tue, Aug 30, 2022 at 04:27:09PM -0700, L L wrote:
I'm on bullseye, and installed chromium from the bullseye repos. In
Chromium I get the message that the browser is "managed by your
organization." I didn't do any special setup for work or school. Is the
management part of the Debian packaging, or is something sketch going on?
There's malware that does that. The feature is usually for things like
company-wide security policy, but if you're not expecting it, it's almost
certainly malware. It's presumably trying to spy on you or serve you ads
or some such.--
The managed message is not malware. It's just part of the standard
configuration in Debian.
If it annoys you, remove the files in /etc/opt/chrome/policies
In my case there is one directory and file that I think are a byproduct
of installing a DICOM viewer
cat /etc/opt/chrome/policies/managed/weasis.json
{
"URLWhitelist": ["weasis://*"]
}
Jeremy
OpenPGP_signature
Description: OpenPGP digital signature
Re: chromium: "Your browser is managed"
On Tue, Aug 30, 2022 at 04:27:09PM -0700, L L wrote: > I'm on bullseye, and installed chromium from the bullseye repos. In > Chromium I get the message that the browser is "managed by your > organization." I didn't do any special setup for work or school. Is the > management part of the Debian packaging, or is something sketch going on? There's malware that does that. The feature is usually for things like company-wide security policy, but if you're not expecting it, it's almost certainly malware. It's presumably trying to spy on you or serve you ads or some such. There's various web pages describing how to remove it; you'll probably need to remove the directory that chromium is storing data in. (Back up bookmarks and such first.) You'll also want to try to figure out how it got installed, and what else might be compromised. Jon Leonard
chromium: "Your browser is managed"
I'm on bullseye, and installed chromium from the bullseye repos. In Chromium I get the message that the browser is "managed by your organization." I didn't do any special setup for work or school. Is the management part of the Debian packaging, or is something sketch going on?
Re: Bug - remote DNS monitoring
> On Aug 30, 2022, at 1:40 PM, Nicholas Geovanis wrote: > > When you run check_dns by hand on Host B, you don't say who you are logged-in > as. That can make a difference. Nagios runs its scripts in a known > environment which may be different than you expect. > Thanks for the question. I have run the check_dns script with: - an arbitrary, unprivileged user - the nagios user (also unprivileged) - root (gasp!) They all work just fine. Also, in every case, I run tcpdump, and I can see the DNS queries and responses going back and forth just fine. In the strace messages, I can also see that the DNS messages were written and read properly. I think the issue is in nslookup, some time *after* the send/recv. But I can't narrow it down much more than that. Casey
Re: Bug - remote DNS monitoring
On Tue, Aug 30, 2022, 2:13 PM Casey Deccio wrote: > Hi all, > > I am having trouble tracking down a bug in my monitoring setup. It all > happened when I upgraded the monitored host (host B in my example below) to > bullseye. Note that Host A is also running bullseye, but the problem > didn't show itself until Host B was upgraded. > > Here is the setup: > > Host A (monitoring): > Installed: nagios4, nrpe-ng > IP address: 192.0.2.1 > > Host B (monitored): > Installed: nrpe-ng, monitoring-plugins-standard, bind9-dnsutils > IP address: 192.0.2.2 > > Host C (monitored through host B): > Installed: bind9 > IP address: 192.0.2.3 > Configured to answer authoritatively for example.com on port 53. > > nrpe > over HTTPs DNS > Host A --> Host B -> Host C > When you run check_dns by hand on Host B, you don't say who you are logged-in as. That can make a difference. Nagios runs its scripts in a known environment which may be different than you expect. On Host B, I run the following: > sudo /usr/bin/python3 /usr/sbin/nrpe-ng --debug -f --config > /etc/nagios/nrpe-ng.cfg > > While that is running, I run the following on Host A: > /usr/lib/nagios/plugins/check_nrpe_ng -H 192.0.2.2 -c check_dns -a > example.com 192.0.2.3 0.1 1.0 > > The result of running the command on Host A is: > DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address > > On Host B, I see the following debug output: > 200 POST /v1/check/check_dns (192.0.2.1) 78.05ms > Executing: /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 > -A -w 0.1 -c 1.0 > > When I run this exact command on Host B, I get: > $ /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 0.1 > -c 1.0 > DNS OK: 0.070 seconds response time. example.com returns > 192.0.2.10,2001:db8::10|time=0.069825s;0.10;1.00;0.00 > > Looks good! When I run nslookup (run by check_dns), it looks good too: > $ /usr/bin/nslookup -sil example.com 192.0.2.3 > Server: 192.0.2.3 > Address: 192.0.2.3#53 > > Name: example.com > Address: 192.0.2.10 > Name: example.com > Address: 2001:db8::10 > > After rerunning nrpe-ng with strace -f, I see something: > > [pid 1183842] write(2, "nslookup: ./src/unix/core.c:570:"..., 83) = 83 > ... > [pid 1183841] read(4, "nslookup: ./src/unix/core.c:570:"..., 4096) = 83 > > So it appears that the nslookup process is reporting an error. But I > cannot reproduce it outside of nrpe-ng. > > Any suggestions? > > Casey >
ledger, libboost and python3.10 in testing?
Hello folks, In testing, ledger returns: ``` ledger: error while loading shared libraries: libboost_python310.so.1.74.0: cannot open shared object file: No such file or directory ``` Do other folks see this? Cheers! -- Boyan Penkov
Bug - remote DNS monitoring
Hi all, I am having trouble tracking down a bug in my monitoring setup. It all happened when I upgraded the monitored host (host B in my example below) to bullseye. Note that Host A is also running bullseye, but the problem didn't show itself until Host B was upgraded. Here is the setup: Host A (monitoring): Installed: nagios4, nrpe-ng IP address: 192.0.2.1 Host B (monitored): Installed: nrpe-ng, monitoring-plugins-standard, bind9-dnsutils IP address: 192.0.2.2 Host C (monitored through host B): Installed: bind9 IP address: 192.0.2.3 Configured to answer authoritatively for example.com on port 53. nrpe over HTTPs DNS Host A --> Host B -> Host C On Host B, I run the following: sudo /usr/bin/python3 /usr/sbin/nrpe-ng --debug -f --config /etc/nagios/nrpe-ng.cfg While that is running, I run the following on Host A: /usr/lib/nagios/plugins/check_nrpe_ng -H 192.0.2.2 -c check_dns -a example.com 192.0.2.3 0.1 1.0 The result of running the command on Host A is: DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address On Host B, I see the following debug output: 200 POST /v1/check/check_dns (192.0.2.1) 78.05ms Executing: /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 0.1 -c 1.0 When I run this exact command on Host B, I get: $ /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 0.1 -c 1.0 DNS OK: 0.070 seconds response time. example.com returns 192.0.2.10,2001:db8::10|time=0.069825s;0.10;1.00;0.00 Looks good! When I run nslookup (run by check_dns), it looks good too: $ /usr/bin/nslookup -sil example.com 192.0.2.3 Server: 192.0.2.3 Address:192.0.2.3#53 Name: example.com Address: 192.0.2.10 Name: example.com Address: 2001:db8::10 After rerunning nrpe-ng with strace -f, I see something: [pid 1183842] write(2, "nslookup: ./src/unix/core.c:570:"..., 83) = 83 ... [pid 1183841] read(4, "nslookup: ./src/unix/core.c:570:"..., 4096) = 83 So it appears that the nslookup process is reporting an error. But I cannot reproduce it outside of nrpe-ng. Any suggestions? Casey
Subject: OT: for posterity: iproute -- dos program by David F. Mischler: (was: CVE security vulnerabilities, versions and ... )
On Wednesday, August 10, 2022 08:55:20 AM Dan Ritter wrote:
> rhkra...@gmail.com wrote:
> > I.e., if a computer on the LAN contacted a computer outside the LAN, NAT
> > would allow incoming data from that external computer, but not allow
> > incoming data from other external computers.
>
> That's a slight confusion of NAT and packet filtering. NAT by
> itself doesn't do that.
Ahh, ok.
For posterity (I sometimes call her pos for short), I wanted to mention a dos
program named iproute written by David F. Mischler.
At most, this has only a slight similarity (it had some features) of the Linux
iproute.
I used it back in the day -- I wish I had kept a record of the incremental
changes I made in my LAN over the years, which at various times:
* included some now defunct hardware ("Network Interface Cards" that were
not Ethernet (well, at least not Ethernet as we knew it then or now -- among
other things it ran on a 93 ohm coax (RG-62 -- I probably still have some
coiled up in the basement if anyone needs it) -- and I've suspected it ran
something like some variation of RS-232 "under the covers", but "they" would
never tell you that.
* I forget which networking software ran on that hardware (under dos or
Windows), but, over the years, I ran quite a variety -- one was named "Lil Big
Lan" and featured an Indian on the logo, another, iirc, was named 10Net (no
relation, afaik) to the 10Net that exists today, and, I don't know, probably
at least 3 or 4 others.
To get more specific about the dos iproute program by Mischler, it was sort of
a monolithic program that could:
* control a dial up modem (it could control something other than an
ordinary dial-up modem, but I never used those at the time, so I don't
remember anything about them
* interface to Ethernet NICs
* do the functions of NAT and some filtering / firewalling (iiuc)
My point (or one of them) is that, being a monolithic program (at least from a
user's point of view), I just thought of it as performing NAT, and my
understanding of NAT was (and still is, I guess) influenced by what that
iproute could do -- it could do all of the things listed below, and I didn't
distinguish between what NAT did and what any built-in filtering / firewalling
may have done.
That iproute was a shareware program, and I think the version I (eventually)
used was v.94 (I may have started with an earlier version. That may have come
into being somewhere in the time period 1992 to 1994:
* that is only a guess based on the earliest dates in the documentation
that I could find for NAT (I believe I found such dates in an RFC, but also
statements in other places that NAT existed (in various forms) before it was
"documented" in an RFC
* another part of my guess is the guess that maybe v.94 was released in
1994.
I used iproute in a dedicated computer, and probably used it until I stopped
using a dial-up modem, which I'm guessing was well after 2000 -- I might have
some clues somewhere in various notes, but I don't want to go looking for them
at the moment.
At some point, version 1.10 was released (that may have been the last release)
and that was somewhat more of a commercial version as opposed to the earlier
shareware versions.
Just to make it clear, iproute could rout (serve as a router) to multiple
computers, I'm sure that I had at least 4 and maybe as many as 7 computers on
my LAN while using iproute.
As an aside, I'm trying to remember if I still used that iproute box when I
switched from coax Ethernet to twisted pair Ethernet -- I would have had to
change the NIC cards -- well, except maybe some of those could use coax or
twisted pair? I'm pretty sure I had some of those.
--
rhk
If you reply: snip, snip, and snip again; leave attributions; avoid HTML;
avoid top posting; and keep it "on list". (Oxford comma included at no
charge.) If you change topics, change the Subject: line.
Writing is often meant for others to read (legal agreements excepted?) -- make
it easier for your reader by various means, including liberal use of
whitespace.
If someone else has already responded to a question, decide whether any
response you add will be helpful or not ...
A picture is worth a thousand words -- divide by 10 for each minute of video
(or audio) or create a transcript and edit it to 10% of the original.
