Could you set the clock back on the server? If it's only used as a mirror to install Linux from it doesn't matter if it has the date wrong.

Chris

Hiding the password is only useful if someone might be watching the screen (it doesn't help if they are watching your fingers as you type a password in). But it's impossible for a password manager to know if someone might be watching the screen, so they always assume the worst.

Chris

From the (CRON) error (can't fork), the oom-killer and Out of memory: messages it looks as if your system ran out of memory. How much ram and swap space does it have? What does free -mt say when it's running OK and when it's having problems?

Chris

To make it work the client needs to know what IP address vmdevuanr1 has. The server will know it's own IP address, probably as 127.0.0.1, so it will work there. The client needs to either have it edited into /etc/hosts when necessary (tedious manual work) or to be able to look it up in DNS.

What does /etc/resolv.conf contain? Mine contains:

nameserver 192.168.1.1

Which tells the system to ask my internet router (at 192.168.1.1) to resolve IP addresses. Try using your router as a DNS server as well as DHCP server. If it's already your DNS server look at it's admin screens to see if there's an option for it to resolve addresses it's handed out by DHCP. Or you may need to add a suffix to vmdevuanr1 in /etc/apt/apt.conf.d/proxy

Chris

Try ping vmdevuanr1 and host vmdevuanr1 on the system you ran apt update on.
(The "Could not resolve 'vmdevuanr1'" message sounds as if it is the key problem.)

Chris

I was just pointing my browser at them, so ignore what I said. The 4 I listed showed a merged directory containing a dists directory with appropriate looking content, so I thought they were the only ones that would work. The rest appeared to fail.

Chris

My /etc/apt/sources.list contains:

## package repositories
deb http://pkgmaster.devuan.org/merged/ ascii main contrib non-free 
deb http://pkgmaster.devuan.org/merged/ ascii-updates main contrib non-free 
deb http://pkgmaster.devuan.org/merged/ ascii-security main contrib non-free 
# deb http://pkgmaster.devuan.org/merged/ ascii-backports main 

## source repositories
# deb-src http://pkgmaster.devuan.org/merged/ ascii main 
# deb-src http://pkgmaster.devuan.org/merged/ ascii-updates main 
# deb-src http://pkgmaster.devuan.org/merged/ ascii-security main 
# deb-src http://pkgmaster.devuan.org/merged/ ascii-backports main 

Checking what IP addresses we are using:

$ host pkgmaster.devuan.org
pkgmaster.devuan.org has address 5.196.38.18

$ host deb.devuan.org
deb.devuan.org is an alias for deb.roundr.devuan.org.
deb.roundr.devuan.org has address 195.85.215.180
deb.roundr.devuan.org has address 37.220.36.58
deb.roundr.devuan.org has address 46.4.50.2
deb.roundr.devuan.org has address 95.216.15.86
deb.roundr.devuan.org has address 91.121.196.103
deb.roundr.devuan.org has address 5.196.38.18
deb.roundr.devuan.org has address 130.225.254.116
deb.roundr.devuan.org has address 185.203.112.44
deb.roundr.devuan.org has address 31.220.0.151
deb.roundr.devuan.org has address 185.26.197.8
deb.roundr.devuan.org has address 200.236.31.1
deb.roundr.devuan.org has address 185.183.113.129
deb.roundr.devuan.org has address 141.24.220.40
deb.roundr.devuan.org has address 37.187.111.86

So pkgmaster.devuan.org points to one of the round robin addresses deb.devuan.org points to. So it should make no difference.

But I'm suspicious of the Connection failed [IP: 37.220.36.58 80] messages you got. And when I look at http://37.220.36.58/merged in a web browser I get a message saying The requested URL /merged was not found on this server.

Try temporarily using pkgmaster.devuan.org and see if that works. Or any other IP address that deb.roundr.devuan.org maps to.

Chris

That could be something accessing the mount point for short intervals. So it's gone when you look for it with lsof. But finding out what it is could be difficult.

You might be able to get round that with a script that retries the unmount a few times if it fails. But that should not be necessary.

Chris

By default sudo will ask for a password the first time you use it, then allow you to use it without asking for a password for 15 minutes. The sudo service clears that so you always get asked for a password the first time you use sudo after a reboot.

You can change how long it remembers by setting timestamp_timeout in /etc/sudoers. Setting it to 0 should make sudo always ask for a password when you use it.

It's a good idea to have another way to get to root (eg su) when experimenting with sudo. So a typo in /etc/sudoers won't lock you out. And keep one terminal session running as root and use another to test sudo as your id.

I'm not sure why you had to add a % to the line in /etc/sudoers.d/[file_name] (mentioned in the other thread). In the line you showed changing groucho to %groucho should make it match members of the group called groucho instead of user groucho. But it's been several years since I've had to use sudo to do more than changing to root.

Chris

Look in /etc/sudoers, there should be something like this:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

If not run visudo as root to add it (visudo edits a copy of /etc/sudoers with vi, then syntax checks your changes and copies it back if they are OK). If you don't know how to use vi then copying the above lines into /etc/sudoers with your favourite editor should work (I'd only recommend this if you can get to root without using sudo, else you could lock yourself out).

Then try sudo -l to list what sudo will let you do. And sudo -i to get to a root shell.

If it still doesn't work post output from sudo -l (lower case L), groups and id.

Chris

Hello,

I've found that the CUDA programs I'm using only work if complied with clang instead of clang-3.8. Which is surprising because they are the same program:

chris@rigel:~$ which clang
/usr/bin/clang
chris@rigel:~$ which clang-3.8
/usr/bin/clang-3.8
chris@rigel:~$ ls -l /usr/bin/clang /usr/bin/clang-3.8
lrwxrwxrwx 1 root root 25 Apr 18  2017 /usr/bin/clang -> ../lib/llvm-3.8/bin/clang
lrwxrwxrwx 1 root root 25 Jun  2  2017 /usr/bin/clang-3.8 -> ../lib/llvm-3.8/bin/clang

Comparing two test cases (test4 fails, test3 works):

chris@rigel:~/msieve-svn1022.test4/trunk/cub$ diff Makefile ~/msieve-svn1022.test3/trunk/cub/Makefile 
20c20
< 			-ccbin clang-3.8 -Xcompiler -fPIC -Xcompiler -fvisibility=hidden
---
> 			-ccbin clang -Xcompiler -fPIC -Xcompiler -fvisibility=hidden

chris@rigel:~/msieve-svn1022.test4/trunk/cub$ ldd sort_engine.so 
	linux-vdso.so.1 (0x00007ffc90ffe000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa9cf8d2000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa9cf6b5000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa9cf4b1000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa9cf29a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa9ceefb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa9cfe30000)

chris@rigel:~/msieve-svn1022.test3/trunk/cub$ ldd sort_engine.so 
	linux-vdso.so.1 (0x00007ffd177ef000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f47b6618000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f47b63fb000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f47b61f7000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f47b5e75000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f47b5b71000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f47b595a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f47b55bb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f47b6b76000)

The error message is:

cannot load library '/home/chris/msieve-svn1022.cuda/trunk/cub/sort_engine.so': /home/chris/msieve-svn1022.cuda/trunk/cub/sort_engine.so: undefined symbol: _ZNSt8ios_base4InitD1Ev

So why does compiling with clang-3.8 produce different output from compiling with clang?

Chris

The only really effective counter to Spectre is not to allow any untrustworthy code to run on your system. Or assume that any code running on it can read (but not update) everything in memory on it. There is no CPU on the market now where you can guarantee there is no exploitable side channel that would leak memory contents.

Chris