Re: [DNG] Weird network issue - slow to resolve IPs [solved]
Quoting goli...@dyne.org (goli...@dyne.org): > With help from my Devuan friends the connection times have improved > significantly. After little poking around and a very interesting > talk with my ISP, I decided that the ISP's DNS resolver was > contributing significantly to the slow connection times. A > suggestion from a Devuan ninja, encouraged me install unbound. Ding! Glad that works for you. (And, as other Dng regulars know, I am a huge fan of doing exactly that.) Yes, ISP recursive nameservers are very frequently awful as to performance. Also as to security, privacy, and reliability, by the way. Which is one of several reasons to try running a recursive DNS daemon of your own, on your own side of the pipe, and use that in preference to other people's recursive nameservers. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Introducing myself....
On Mon, Oct 15, 2018 at 01:42:04PM +0100, g4sra wrote: [cut] > > As an experienced systems administrator with strong gut instincts I can > 'bolt stuff together' that 'just works' 24x7x365. Unfortunately, I am > only a mediocre programmer, but despite that is my intention to > contribute to Devuan what little I can and try to keep my mouth shut > about the stuff I don't know. > > What I am looking for from the Devuan community now is an open > discussion about the alternative init systems, what is available (I have > googled and read a little), when to use which, and a very good reason > why I shouldn't just boot straight into bash and go it alone with a bit > of python ;) Welcome g4sra, we have had this discussion several times int he last four years, so maybe having a look at the archives of this ML would be a good start. At the moment, ASCII supports both sysvinit and OpenRC. The plan is to add more init systems and/or process supervision systems starting with Beowulf. The basic idea is that the supported init system should be available as a choice at install time. This list can be vocal at times, but I guess that's normal with hundreds people around ;) Devuan development discussions are happening on devuan-dev, same server. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Introducing myself....
Been reading the mail... Having read some of the answers given by Lennart for the reasons he has or has not implemented something I personally think the guy is a prat (or at least socially inept). Having said that there are plenty that regard me the same way. I have no opinion on the 'quality' of his code as I have never even bothered to look at it, that is a different issue. The issue as I see it is that Linux is becoming commercialised by the likes of Red Hat and other big players (Oracle, IBM, etc, etc). Having worked with large businesses I understand why SystemD appeals, after all it is targeted specifically at them to make their life more profitable. Lennart is doing what his employer is asking from him. It is these large companies (that are now steering the direction that Linux is moving in) that should be the target of our suspicion and distrust. SystemD OS (it should be called that, recalling my University years of the functionality required to create an 'Operating System', it is almost complete and distinct by it's nature from GNU\Linux) is what it is, and is not for me. I have no interest or use for in a Linux optimised for running on AWS under mass administration by a semi-skilled team on my workstation or embedded devices. This is why I am now turning to Devuan. Devuan has the potential to be a strong community supported distribution if instead it it is a place for embittered opinionated flaming, I, and many others will look elsewhere. As an experienced systems administrator with strong gut instincts I can 'bolt stuff together' that 'just works' 24x7x365. Unfortunately, I am only a mediocre programmer, but despite that is my intention to contribute to Devuan what little I can and try to keep my mouth shut about the stuff I don't know. What I am looking for from the Devuan community now is an open discussion about the alternative init systems, what is available (I have googled and read a little), when to use which, and a very good reason why I shouldn't just boot straight into bash and go it alone with a bit of python ;) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
On 2018年10月16日 11:16:30 JST, goli...@dyne.org wrote: >> On Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote >> >It is incredibly annoying to be connected to a rather fast pipe yet >have >to travel on what feels like 56k connection to get to where I can >benefit from it. >> >> golinux >> > >With help from my Devuan friends the connection times have improved >significantly. After little poking around and a very interesting talk >with my ISP, I decided that the ISP's DNS resolver was contributing >significantly to the slow connection times. A suggestion from a Devuan >ninja, encouraged me install unbound. I was instructed to put the IP in > >/etc/resolv.conf and to enable the prepend (I can't remember exactly >where). Now my connection times are mostly pretty snappy. > >This has been an interesting, informative thread and I appreciate >everyone who shared their thoughts. > >Till next time, > >golinux > Hi, Happy to know u solved the problem. By the way, that means that was not some No-Net-Neutrality's effect if I understand correctly. All the best, ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs [solved]
On Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote It is incredibly annoying to be connected to a rather fast pipe yet have to travel on what feels like 56k connection to get to where I can benefit from it. golinux With help from my Devuan friends the connection times have improved significantly. After little poking around and a very interesting talk with my ISP, I decided that the ISP's DNS resolver was contributing significantly to the slow connection times. A suggestion from a Devuan ninja, encouraged me install unbound. I was instructed to put the IP in /etc/resolv.conf and to enable the prepend (I can't remember exactly where). Now my connection times are mostly pretty snappy. This has been an interesting, informative thread and I appreciate everyone who shared their thoughts. Till next time, golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
Quoting Alessandro Selli (alessandrose...@linux.com): > "Go to 'Settings', 'Network' and 'Search the local network', when you > see the icon with the printer double click on it and accept the download > of the driver and install it if you don't have it". > > This is the answer I get 99% of the times when I ask. Yeah, well, if I got that, I'd pretend to be really grateful, say 'Thank you _so_ very much!', and then go quietly figure out the real answer for myself. https://rationalwiki.org/wiki/Dunning-Kruger_effect (See also .signature block.) -- Cheers, "It ain't so much the things we don't know that get us Rick Moenin trouble. It's the things we know that ain't so." r...@linuxmafia.com -- Artemus Ward (1834-67), U.S. journalist (attr.) McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
On 15/10/18 at 20:12, Rick Moen wrote: [...] > Or, if there's someone technical handy, I lazily ask 'Hey, how would I > print directly to this printer?' "Go to 'Settings', 'Network' and 'Search the local network', when you see the icon with the printer double click on it and accept the download of the driver and install it if you don't have it". This is the answer I get 99% of the times when I ask. Because no one in the building remembers or ever knew what the printer's IP is. At most they'd tell me it's name. Alessandro -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
On Mon, 15 Oct 2018 11:12:41 -0700 Rick Moen wrote: > Quoting Didier Kryn (k...@in2p3.fr): > > > This is fine if you always work in the same place. During my > > professional life, I used to travel to various labs and found it > > convenient to automatically find, in the cups menu of my laptop, a > > list of the local printers. And to always have the list up to date > > when the computing department installed/removed old/new printers. > > I respect that. For the sake of community knowledge, I'll also tell > you what I do as an alternative: > > When I visit a new location, I look around for a networked printer, > and see if it happens to have a label on it including its IP address > (usually not). If not, I can usually figure out from the printer's > front-panel controls how to make it print out an information sheet to > proclaim its network access details. (For example, all HP laser > printers have a standard way to do this.) If I cannot easily figure > that out, I type its make/model into a Web browser to look up how on > the Web. Either way, within a couple of minutes, I know details of > how to print on it, usually over my choice of several protocols (lpr, > ipp, etc.) > > Or, if there's someone technical handy, I lazily ask 'Hey, how would I > print directly to this printer?' > > > And a possibly amusing cautionary tale: After the dot-com collapse, a > small firm named California Digital Corporation (CDC) picked up the > hardware business that Larry Augustin decided my old firm VA Linux > Systems could no longer compete in, resuming manufacture and sale of > VA Linux's models (and successors to those) under their new brand. > (Incidentally, they showed that Augustin's pessimistic conclusion had > been in error, as they were prosperous in that industry segment for > quite a few years, and had numerous achievements to boast, including > building for Lawrence Livermore Labs the #2 HPC cluster in the world, > a 1024 quad-Itanium computing cluster named 'Thunder'.) > > CDC was run by a husband and wife firm, the Aruns. I was for a while > their system administrator and de-facto IT guy. One morning, I walked > in, and Ms. Arun was very vexed, because she said that printing was > not working anywhere around the firm. Notably, she said there had > been a power outage right at the beginning of the business day. > > I conducted tests of printing to several of the HP JetDirect printers > across the network, and everything worked fine. Moreover, all of the > technical staff were having no problem at all printing. It was just > the executive staff reporting total printing failure. > > Getting to the bottom of the problem required looking at the printing > setup objects of those people's -- yes -- Microsoft Windows > workstations. Each of them had a printer object that was defined as a > queue on the controller's (the main company accountant's) workstation. > Every single executive was routing all print jobs through that poor > fellow's workstation, before those jobs then recrossed the network out > to the printer near the executive offices. (Meanwhile, the technical > staff were enjoying faster, more reliable, more direct printing.) > > As it happened, the controller's workstation had an ATX power supply > that was set to put the workstation in standby power mode after a > power loss, rather than come back online. So, from > > I politely asked 'Why aren't people printing directly to the executive > LaserJet?' -- and, predictably, heard 'How do you do that?' > > It seems that someone had originally helped the controller print to > the executive printer and, in so doing, had created on that > workstation a Network Neighbourhood queue object, advertised to the > network. Subsequently, every time someone on the executive staff set > up printing, he/she groped in Network Neighbourhood, found the > accountant's printing object, and assumed that was the only way to > reach the executive printer. > > I re-did all of the executives' printing so that they did JetDirect > printing straight to the printer, replacing their convoluted and > fragile workaround. > > This is part of why I would rather not trust to automated printer > discovery. I'd rather know what I'm doing, instead of assuming > someone else knows what's good for me, as that often is not the case. > This reminds of the time I was asked at work why printing was so slow. This was after a so called expert had supposedly set up the network. It was years ago and it was a small XP workgroup, I traced it down to the print server the 'expert' had installed on the network and connected to the main printer i.e. the one everybody used. This by itself wasn't the problem, the problem was that he had then setup the printer driver on one PC and then shared it across the network, all printing went through that PC. After I spent about an hour sorting this out and print speed went up by a large amount, the 'expert' was asked not to come back
Re: [DNG] Avahi [was Weird network issue]
Quoting Didier Kryn (k...@in2p3.fr): > This is fine if you always work in the same place. During my > professional life, I used to travel to various labs and found it > convenient to automatically find, in the cups menu of my laptop, a > list of the local printers. And to always have the list up to date > when the computing department installed/removed old/new printers. I respect that. For the sake of community knowledge, I'll also tell you what I do as an alternative: When I visit a new location, I look around for a networked printer, and see if it happens to have a label on it including its IP address (usually not). If not, I can usually figure out from the printer's front-panel controls how to make it print out an information sheet to proclaim its network access details. (For example, all HP laser printers have a standard way to do this.) If I cannot easily figure that out, I type its make/model into a Web browser to look up how on the Web. Either way, within a couple of minutes, I know details of how to print on it, usually over my choice of several protocols (lpr, ipp, etc.) Or, if there's someone technical handy, I lazily ask 'Hey, how would I print directly to this printer?' And a possibly amusing cautionary tale: After the dot-com collapse, a small firm named California Digital Corporation (CDC) picked up the hardware business that Larry Augustin decided my old firm VA Linux Systems could no longer compete in, resuming manufacture and sale of VA Linux's models (and successors to those) under their new brand. (Incidentally, they showed that Augustin's pessimistic conclusion had been in error, as they were prosperous in that industry segment for quite a few years, and had numerous achievements to boast, including building for Lawrence Livermore Labs the #2 HPC cluster in the world, a 1024 quad-Itanium computing cluster named 'Thunder'.) CDC was run by a husband and wife firm, the Aruns. I was for a while their system administrator and de-facto IT guy. One morning, I walked in, and Ms. Arun was very vexed, because she said that printing was not working anywhere around the firm. Notably, she said there had been a power outage right at the beginning of the business day. I conducted tests of printing to several of the HP JetDirect printers across the network, and everything worked fine. Moreover, all of the technical staff were having no problem at all printing. It was just the executive staff reporting total printing failure. Getting to the bottom of the problem required looking at the printing setup objects of those people's -- yes -- Microsoft Windows workstations. Each of them had a printer object that was defined as a queue on the controller's (the main company accountant's) workstation. Every single executive was routing all print jobs through that poor fellow's workstation, before those jobs then recrossed the network out to the printer near the executive offices. (Meanwhile, the technical staff were enjoying faster, more reliable, more direct printing.) As it happened, the controller's workstation had an ATX power supply that was set to put the workstation in standby power mode after a power loss, rather than come back online. So, from I politely asked 'Why aren't people printing directly to the executive LaserJet?' -- and, predictably, heard 'How do you do that?' It seems that someone had originally helped the controller print to the executive printer and, in so doing, had created on that workstation a Network Neighbourhood queue object, advertised to the network. Subsequently, every time someone on the executive staff set up printing, he/she groped in Network Neighbourhood, found the accountant's printing object, and assumed that was the only way to reach the executive printer. I re-did all of the executives' printing so that they did JetDirect printing straight to the printer, replacing their convoluted and fragile workaround. This is part of why I would rather not trust to automated printer discovery. I'd rather know what I'm doing, instead of assuming someone else knows what's good for me, as that often is not the case. > >(Check the authors of Avahi, and you'll see a familiar name.) > > I guess some Lennart guy is involved. Got it in one. > I don't think he is pure evil. Nor I. I just find it amusing that he went out of his way to implement a network protocol that I consider a blight on networks, a thing that IMO is best eliminated. Back in the 1980s, I worked as IT staff (or, as we then said, MIS) at a firm called Blyth Software. This was just before the transition from network hubs to network switches, where the latter implicitly helped alleviate network congestion by localising traffic. Blyth's LAN was a somewhat monstrous thing with an odd history, and putting a network analyser box onto it revealed interesting things, which we spent some time studying. In those days, if there was a cable problem, or a failing/chattering ethernet card,
[DNG] DSA Ascii 15Oct
Sun, 14 Oct 2018 19:00:58 + [SECURITY] [DSA 4317-1] otrs2 security update version 5.0.16-1+deb9u6 Confirmed: ascii-security Fri, 12 Oct 2018 20:55:21 + [SECURITY] [DSA 4316-1] imagemagick security update version 8:6.9.7.4+dfsg-11+deb9u6 Confirmed: ascii-security Fri, 12 Oct 2018 20:45:26 + [SECURITY] [DSA 4315-1] wireshark security update version 2.6.3-1~deb9u1. This update upgrades Wireshark to the 2.6.x release branch, future security upgrades will be based on this series. Confirmed: ascii-security Note: beowulf and ceres contain v2.6.3-1 Thu, 11 Oct 2018 19:40:56 + [SECURITY] [DSA 4314-1] net-snmp security update version 5.7.3+dfsg-1.7+deb9u1 Confirmed:ascii-security, ascii-proposed-updates Mon, 08 Oct 2018 20:48:42 + [SECURITY] [DSA 4313-1] linux security update version 4.9.110-3+deb9u6 Confirmed: ascii-security Mon, 08 Oct 2018 17:13:25 + [SECURITY] [DSA 4312-1] tinc security update version 1.0.31-1+deb9u1 Confirmed:ascii-security, ascii-proposed-updates Fri, 05 Oct 2018 19:29:29 + [SECURITY] [DSA 4311-1] git security update version 1:2.11.0-3+deb9u4 Confirmed:ascii-security, ascii-proposed-updates Wed, 03 Oct 2018 19:00:47 + [SECURITY] [DSA 4310-1] firefox-esr security update version 60.2.2esr-1~deb9u1 Confirmed:ascii-security, ascii-proposed-updates Tue, 02 Oct 2018 09:36:09 +0200 [SECURITY] [DSA 4309-1] strongswan security update version 5.5.1-4+deb9u4 Confirmed:ascii-security, ascii-proposed-updates ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] passwordless console autologin
Am 12. Oktober 2018 18:43:51 MESZ schrieb Alessandro Selli : > Passwordless accounts is a feature that was taken over by PAM. Hallo Alessandro, thanks for your reply - as it is only a slight change to my previous configuration, fsmithreds solution perfectly suits my needs and works very well, so I'll stick with that: The autologin starts the videoplayer via .bashrc (startx) and .Xsession. If it exits for any reason, it gets automatically restarted: a very simple "videoplayd" (full documentation yet to be written). Libre Grüße, Florian -- [message sent mobile] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Kernel SUID sandbox
On 15/10/18 at 10:55, Lars Noodén wrote: > I notice that in Ascii with both the stock kernel and the one from > backports (4.17.0-0.bpo.1-amd64) some applications cannot run. For > example the web browser Brave fails with this message: > > [9394:9394:1015/111632.363017:FATAL:zygote_host_impl_linux.cc(116)] > No usable sandbox! Update your kernel or see > https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md > for more information on developing with the SUID sandbox. If you want to > live dangerously and need an immediate workaround, you can try using > --no-sandbox. > Trace/breakpoint trap Reading the bug report turns out the issue is lack of an appropriate namespace sandbox: https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md «Linux SUID Sandbox Development» "IMPORTANT NOTE: The Linux SUID sandbox is almost but not completely removed. See https://bugs.chromium.org/p/chromium/issues/detail?id=598454 This page is mostly out-of-date. For context see LinuxSUIDSandbox We need a SUID helper binary to turn on the sandbox on Linux." https://bugs.chromium.org/p/chromium/issues/detail?id=598454 says: «Stop checking for the setuid sanbox binary on desktop Linux» "As per bug 312380 , we should no longer need the setuid binary sandbox on most if not all supported versions of desktop Linux. However, Chrome still checks for it on startup and complains if it's not there. We should stop doing that." "The intention is if you want to run Chrome and only use the namespace sandbox, you can set --disable-setuid-sandbox. But if you do so on a host without appropriate kernel support for the namespace sandbox, Chrome will loudly refuse to run." Namespaces have been available in Linux for a long time: https://lwn.net/Articles/528078/ «User namespaces progress» "The first pieces of the implementation started appearing when Linux 2.6.23 (released in late 2007)" there's no doubt 4.17 kernels have it. There's something in your system setup that is missing or not adequately configured (Apparmor, maybe?). Alessandro -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Kernel SUID sandbox
I notice that in Ascii with both the stock kernel and the one from backports (4.17.0-0.bpo.1-amd64) some applications cannot run. For example the web browser Brave fails with this message: [9394:9394:1015/111632.363017:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox. Trace/breakpoint trap This is not an issue in Linux Mint. Perhaps it is a problem upstream in Debian? /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Avahi [was Weird network issue]
Le 14/10/2018 à 22:42, Rick Moen a écrit : Quoting Didier Kryn (k...@in2p3.fr): Avahi daemon is the Linux dnssd service. dnssd is a protocol for service discovery on LAN (formerly known as Apple "Bonjour"). The essential utility for me is to allow to discover CUPS servers on the LAN, because recent versions of CUPS advertise their presence by the dnssd protocol instead of the former ad hoc protocol. dnssd is the most annoyingly and pointlessly chatty network protocol since Appletalk. If like me you don't want that crud junking up your network, edit the line 'BrowseRemoteProtocols dnssd cups' in cupsd.conf to 'BrowseRemoteProtocols none' and restart cupsd. Blessed silence will ensue. This is fine if you always work in the same place. During my professional life, I used to travel to various labs and found it convenient to automatically find, in the cups menu of my laptop, a list of the local printers. And to always have the list up to date when the computing department installed/removed old/new printers. This of course requires determining a target printer's IP address and supported network transports, when configuring printing, rather than having it be automagical. (Quelle horreur!) (Check the authors of Avahi, and you'll see a familiar name.) I guess some Lennart guy is involved. I don't think he is pure evil. The problem is that he hasn't simplicity amongst his targets. But a few of his things works, like avahi and ifplugd. Maybe Avahi is chatty, but I never found it on my way reversing any of my configuration choices or forcing anything on me. After all it is just the implementation on Linux of a protocol which is now a multi-os standard, even if it originated in Apple (which isn't a criteria of quality). I think one has to remain realistic and only avoid potterware when there is choice. There is concerning systemd, thanks Devuan, and a few other, and there is concerning pluseaudio, thanks apulse. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
