Re: vbox cannot find headers, although they are installed
On Sat, January 6, 2018 11:36 pm, Harry Putnam wrote: ... > (Look at /var/log/vboxadd-install.log to find out what went wrong) ... the line above can explain a lot. cheers. -- x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE "I don't know where I'm going from here, but I promise it won't be boring." - David Bowie
Re: is there any Windows virus that affect linux?
On Wed, December 13, 2017 2:41 pm, Stefan Monnier wrote: >> The weakest link in most chains of Data protection is the person that >> has access to it. > > And rather than breaking knuckles, sometimes it's more ...elegant.. to > just fool/seduce the target, > > > Stefan We know. Poor Assange... but it was a beautiful job. cheers. -- x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: is there any Windows virus that affect linux?
On Wed, December 13, 2017 6:17 am, to...@tuxteam.de wrote: ... > If they target *you* individually, yes, they have cheaper means at > their disposal. That's called "rubber hose cryptanalysis"[1] -- not > pretty. Or, as Schneier put it "the NSA is better at breaking knuckles > than at breaking codes". > > Still, for an attack of the Natanz type, they seem to have picked > the Stuxnet way, and you and me might end up as collaterals. so true. > [1] Or, as XKCD puts it, in a similarly charming way, "$5 wrench > cryptanalysis" ><https://www.xkcd.com/538/> I luv that comic :) cheers. -- x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: is there any Windows virus that affect linux?
On Tue, December 12, 2017 8:00 am, to...@tuxteam.de wrote: ... > That said, this kinds of attacks are so complex that (as in the > case of Stuxnet) it possibly takes the resources of a nation-state > (or, in this case, probably two) to set something up like that. > OTOH things are pretty fluid these days, so I wouldn't count on > that staying the same for a long time. > > So to sum up -- you'll have to read up on many things to even > understand an answer to your question. My current answer would > be (to some high, but unspecified degree of probability) "No", > but that might change whithin the next couple o'years. > ... If a nation-state wanna play games with you, there are a lot of more important things you should really care about... ps: ELF --> PE infection on FAT/FAT32/NTFS partition on same disk, unencrypted (quite easy) PE --> ELF infection on ext? partition on same disk, unencrypted (bit more of work) cheers. -- x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Upgraded to stretch but apache2 still uses php5
The downside of upgrading php5 -> php7 is.. some apps can break. Still, there are some workarounds to make them work with php7 (most of cases). check if you have libapache2-mod-php7.0 installed. remove/purge any other previous versions of this package and restart apache2. after that, check if there is still something there with: # egrep -rs php5 /etc/apache2/ also in hole system: dpkg -l | egrep php5 If so, repeat process of upgrade the packages, restart apache2 PS: Assuming your apps works with php7 cheers. x9p > I thought I'd try a better webmail than squirrelmail, so I tried to install roundcube. After many hours I gave up (missing php pdo modules), purged it all, and then tried a non-debian package: rainloop. I spent may hours with it, trying to solve missing php curl modules. > What had me going in circles in both cases was that php was telling me that the missing modules were in fact there. > I finally realized that the php cli is v7.0, whereas apache2 runs runs with php5. There are all sorts of apache2 config files for php7 but apache2 is still using php5. php7 has the pdo and curl modules, but I think the php5 modules were uninstalled during the upgrade to stretch. I don't know if it is intentional that the apache2 environment didn't change to the newer php7? If it should be using php7, how do I go about forcing the change, and is there any downside to doing this? > Regards, > Rick
Re: estamated number of Linux users?
On 2017-10-27 16:41, John Hasler wrote: Ric writes: I wouldn't demean the Linux Counter effort calling it "Utterly useless". It's a simple statement of fact. The Linux Counter data is utterly useless for the purpose of estimating the number of Linux users. :%s/Linux/active Linux/g
Re: estamated number of Linux users?
On 2017-10-27 14:27, Ric Moore wrote: On 10/26/2017 11:21 PM, John Hasler wrote: Celejar writes: https://www.linuxcounter.net/ I don't know how meaningful its data are. Utterly useless. I wouldn't demean the Linux Counter effort calling it "Utterly useless". Those folks have maintained the site since 1999 or so. It is what it is... a database of users who have bothered to have themselves counted as a Linux User. They don't claim to be anything else. Ric Just for the fun of it, if really interested on that, maybe build a script to parse the archives of the public mailing lists for the main Linux distros, getting the last active unique emails for the past 6 months... and count them. just an idea tough...
Re: Wifi works in Ubuntu and not in Debian
Hi > The strange was that in Ubuntu 17.04, was fill the fields and connect. In > Debian, using the sames files and parameters, returns some times asking > again the password. > Does you mean wpa successfully connects to the Wifi also in debian but it disconnects later? > Taking a look in syslog, I found a error in wpa_suppliant: > > Sep 14 15:51:58 nx01 wpa_supplicant[839]: OpenSSL: tls_connection_ca_cert > - > Failed to load root certificates error::lib(0):func(0):reason(0) > Trying to find some thing in Google, I couldn't found any thing that > explain what to do or what happens. > > Some suggestion or tip? > Could you post both versions (ubuntu and debian) of wpa-supplicant and openssl? also the command line from both systems while running wpa_supplicant: #ps -ef | egrep wpa #dpkg -l | egrep 'openssl|wpa' > Since now, I thank in advance. > > Regards, > Claudio Ferreira > cheers. x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> True, we know the OP has a problem with with sudo. What we do not know > is the hostname he chose during the installation, although it looks like > it was "localhost" from the second line of > > 127.0.0.1 localhost > 127.0.1.1 localhost > root@localhost:~# cat /etc/hostname localhost > The installer recommends a single word for the hostname. The "single" > aspect is the result of a number of years of experience and bug reports. > Although "localhost.localdomain" is not an invalid hostname the OP does > not appear to have used it. (We have not been given the contents of his > /etc/hostname explicitly). > I agree choosing "localhost" is wrong per-RFC. But I have been doing it for years and stuff never broke. stretch+sudo 1.8.19p1-2.1 is a first. Bad luck of me. > What was the problem with his resolv.conf? Have I missed that? > Hardcoded company nameserver in /etc/resolv.conf that only works when VPN is up. VPN was down and problem appeared. x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
>> >> I believe topic is closed with this. > > For the benefit of other users: what does your /etc/hosts look like now? > > -- > Brian. > > root@localhost:~# cat /proc/sys/kernel/hostname localhost.localdomain root@localhost:~# grep localhost /etc/hosts 127.0.0.1 localhost localhost.localdomain 127.0.1.1 localhost ::1 localhost ip6-localhost ip6-loopback root@localhost:~# x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
>> >> My chosen machine name was "localhost", problem partially lies here. > > Yeah, man. > > My uncle Harry had a similar problem when it occurred to him that--for > reasons of simplicity and because of a failing memory--he might christen > two recently-purchased kittens with identical names. Whenever he called > one of them there would be a considerable delay (each of them assuming > he was calling the other). > > Of course cats never come when you call them anyway (which is a clue > the story may be apocryphal). > > BTW, did you get the memo? > > http://www.ietf.org/rfc/rfc1912.txt > > >From rfc1912: - Translating 127.0.0.1 into "localhost.dom.ain" can cause some software to connect back to the loopback interface when it didn't want to because "localhost" is not equal to "localhost.dom.ain". - Thanks for the memo. Seems the solution is to not call machine localhost, if insist in doing so, be sure it contains a "localhost.localdomain" line in /etc/hosts. I believe topic is closed with this. Thanks x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> > This is the default from the last stretch install > > $ cat /etc/hosts > 127.0.0.1    localhost > 127.0.1.1    fujitsu.mydomain   fujitsu > > so if mydomain or localdomain is not working it will delay. > > 127.0.1.1 fujitsu fujitsu.mydomain > > will not delay because fujitsu is the name of the machine. > > in my case mydomain was added at installation time, because cable was > plugged in and the computer (fujitsu) got its IP via the dhcp server on > the > local network. > > IMO you should look deeper in your use case and see why you get invalid > setup. The problem might be somewhere else. > > regards > > My chosen machine name was "localhost", problem partially lies here. x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> The last time I recollect this "someone" sticking his head above the parapet was in the thread beginning at > https://lists.debian.org/debian-devel/2013/07/msg00809.html >From the above URL: From: Christoph Anton Mitterer <cales...@scientia.net> Date: Tue, 30 Jul 2013 22:43:44 +0200 - - The system hostname (and domainname if any) should ALWAYS be resolvable, whether a network is up or not, regardless of which. (Assuming that lo is always up, if not, many things break anyway.) - "localhost" when added like this to /etc/hosts is basically like a TLD. "localhost" is one of the reserved names, unlike ip6-localhost and friends and unlike .localdomain. ... ... ... Further, but this isn't the case anymore anyway,... we should not generate localhost.localdomain. ... ... ... - If system hostname should ALWAYS be resolvable, whether there is network or no, the change in /etc/hosts from (default in stretch): 127.0.0.1 localhost to (my system): 127.0.0.1 localhost localhost.localdomain is justifiable as it breaks (not literally break, just adds lot of delay) to sudo in a non-networked environment. x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> Since the /etc/hosts file can also contain aliases, the ideaL way would > seem to be to make use of that. Example: > 192.168.x.z localhost.localdomain localhost > You are right, this solves the problem of the DNS lookup / X seconds delay to run sudo even with a buggy DNS server: root@localhost:~# head -1 /etc/hosts 127.0.0.1 localhost localhost.localdomain Should be on debian by default in my opinion. x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> Thanks, now I see it.
>
> Your /etc/hosts says:
>
> 127.0.0.1 localhost
> 127.0.1.1 localhost
> ::1 localhost ip6-localhost ip6-loopback
>
> Note the absence of localhost.localdomain.
>
>
> Your hostname is "localhost.localdomain", as strace helpfully shows us:
>
> uname({sysname="Linux", nodename="localhost.localdomain", ...})
>
strangely i do not remember calling it localhost with domain localdomain,
just localhost.
>
> I won't say that specifying fqdn as nodename is wrong per se, but in
> your case you don't have a record for your hostname in /etc/hosts.
>
> This *could* be the case that's nss-myhostname is designed for but â¦
> it's the last in your nsswitch.conf so it cannot come into play.
>
> Therefore libc resolver you're using does exactly the same way it's
> supposed to - search for localhost.localdomain in /etc/hosts first,
> query DNS next.
>
>
> Quick and dirty way to fix this is to add a record for
> 'localhost.localdomain' in your /etc/hosts.
>
Will do it, thanks
> Correct, but painful way (I won't even try to predict what you could
> break in your setup) to fix this is to ensure that your hostname is
> 'localhost' verbatim.
>
I still think correct way is sudo not try to access network functions in a
setup where it does not need to - waste of time, code, and opens it to
more bugs.
Thanks for the analysis Reco.
x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> You should have a localhost entry in /etc/hosts. If you have > configured your /etc/sudoers to specify "localhost.localdomain", > then you should also have a localhost.localdomain entry in > /etc/hosts, or your should change the sudoers config to just > reference "localhost". > No changes were made to the /etc/sudoers except this: myuser ALL=(ALL) NOPASSWD:ALL I did not touched any Host_List. Debian by default do not come with localhost on /etc/sudoers. sudo binary does come with the "localhost" string in it. root@localhost:~# strings /usr/bin/sudo | egrep localhost localhost x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> Your snippet of strace output on pastebin is lacking the beginning. > What I'm currently interested in are: > > 1) Libraries and configuration files that sudo is opening (hence the > 'open' syscall). Thinking about it, make it 'open,stat'. > > 2) What kind of network sockets (short of kinda obvious UDP) sudo is > opening (hence the 'connect' syscall). > Sorry for that, pasted the full output here. https://pastebin.com/0bV7JC1z > Feel free to edit out all unnecessary details of course. No need. > > PS Replying to debian-user@lists.debian.org is sufficient. There's no > need to CC me, I'm subscribed to the list. > Sorry for that. I just hit "reply all", fixing. x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> sudo(8) says: > > sudo supports a plugin architecture for security policies and > input/output logging. Third parties can develop and distribute their > own policy and I/O logging plugins to work seamlessly with the sudo > front end. The default security policy is sudoers, which is configured > via the file /etc/sudoers, or via LDAP. > > And LDAP means TCP, and TCP usually mean DNS requests. > > So it's unusual (sudo does not exhibit such behavior here), but > possible. > Agree there are situations where sudo does TCP. Disagree with that occurring in my simplistic setup. sudo should not hang for X seconds if my DNS servers are incorrect. > A stray nameserver in resolv.conf, which can happen if resolvconf is > used carelessly. Even more weird things are always possible with > NetworkManager. Am too old, I like /etc/resolv.conf being just a file. Am avoiding to turn this into a systemd talk. >> resolv.conf is not a symlink to systemd, just a plain file. I explicitly >> removed the symlink and created a normal file. > > And of course one can never disregard a misconfigured VPN script. > > > >> > Specifically I'm interested with: >> > >> > grep hosts /etc/nsswitch.conf >> > >> > grep localhost /etc/hosts >> > >> > Reco >> > >> >> Did not touched these, are the default from stretch: >> >> root@localhost:~# grep hosts /etc/nsswitch.conf >> hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname >> root@localhost:~# grep localhost /etc/hosts >> 127.0.0.1 localhost >> 127.0.1.1 localhost >> ::1 localhost ip6-localhost ip6-loopback > > Curious. Can you reproduce the behaviour if sudo is run as root? > I propose to simplify things a bit (needs to be run as root): > strace was already run as root (did "sudo su" as root to prove the point), otherwise strace would fail with "effective uid is not 0". x9p
Re: sudo slow on DNS lookup, with invalid resolv.conf entries
> Hi.
Hi.
>
> While DNS lookups for localhost are unusual any reasonable configured
> DNS should have no trouble resolving it. Especially since there are OSes
> that try to resolve *everything* by default via including localhost (AIX
> comes to mind).
>
Understand, but disagree with sudo doing DNS lookups. Will fill a bug with
them.
> While you mentioned misconfigured resolv.conf I believe your problem
> lies somewhat deeper than this.
Actually it is deeper. I did not pay that much attention to the strace I
did before.
https://pastebin.com/j0rw5Kgn
10.1.2.9 is the DNS of the company I work for, turned out I had not
connected to the VPN yet by the time i issued the sudo command.
---
connect(6, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.1.2.9")}, 16) = 0^M
poll([{fd=6, events=POLLOUT}], 1, 0)= 1 ([{fd=6, revents=POLLOUT}])^M
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2^M
poll([{fd=6, events=POLLIN}], 1, 5000) = 0 (Timeout)^M
---
resolv.conf is not a symlink to systemd, just a plain file. I explicitly
removed the symlink and created a normal file.
> Specifically I'm interested with:
>
> grep hosts /etc/nsswitch.conf
>
> grep localhost /etc/hosts
>
> Reco
>
Did not touched these, are the default from stretch:
root@localhost:~# grep hosts /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
root@localhost:~# grep localhost /etc/hosts
127.0.0.1 localhost
127.0.1.1 localhost
::1 localhost ip6-localhost ip6-loopback
x9p
sudo slow on DNS lookup, with invalid resolv.conf entries
I was getting > 30sec to complete "sudo su" on a host. This host had
invalid entries in resolv.conf and I realized sudo was doing 5 seconds
lookup on each entry searching for "localhost.localdomain"
sudo is 1.8.19p1 @ stretch.
Believe no DNS lookups should be made... even for localhost
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\313\265\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=51}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\371\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=51}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\313\265\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=51}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\371\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=51}], 2, MSG_NOSIGNAL) = 2
