To run tests on the development build of my program I need to isolate it from the network.
The build still needs access to loopback (127.0.0.1) though.
I tried using unshare -c -n <program> but the loopback interface is down by default.
Using unshare -r -n bash allows me to enable the interface by using ip link set lo up but the program needs to be invoked manually in that bash shell then.
I tried to create a persistent network namespace (ip netns add vnet1) but that only works with sudo which I need to avoid.
So it is possible to create a unshared network namespace with lo down, without using sudo.
I need to get the lo interface up before launching the build. Ideally I'd integrate the the setup in a bash script without using privilege escalation.
I've read that fedora provides a enabled loopback interface by default, so can I adjust this behavior with sysctl etc. ? (I'm on archlinux)
Related
I am aware that you can launch docker containers remotely in VSCode. Is it possible to do the same with singularity containers?
Update: the solution to this was published in the same issue (https://github.com/microsoft/vscode-remote-release/issues/3066#issuecomment-1019500216) as before by user oschulz:
As promised, here are some instructions on how to use Singularity with VS-Code Remote SSH via SSH RemoteCommand. The procedure described below makes VS-Code run it’s remote server component inside a Singularity container instance (other runtimes like Shifter work too).
Acknowledgement: Credit for a lot of this goes to #gipert, who refined my original approach (using a custom SSH script) when support for RemoteCommand became available in VS-Code recently
Step 1
Use VS-Code >= v1.64 (includes support for the SSH RemoteCommand setting). Install the Pre-Release version of the Remote SSH extension
Important: In the VS-Code settings, set "remote.SSH.enableRemoteCommand": true.
Step 2
In your "$HOME/.ssh/config", add something like
Host myimage1~*
RemoteCommand singularity shell /path/to/image1.sif
RequestTTY yes
Host myimage2~*
RemoteCommand singularity shell /path/to/image2.sif
RequestTTY yes
Host somehost myimage1~somehost myimage2~somehost
HostName some.host.somewhere
User your_username_
Host otherhost myimage1~otherhost myimage2~otherhost
HostName some.otherhost.somewhere
User your_username_
Test whether this works using ssh myimage1~somehost. This should drop you into an SSH session inside of an instance of the "/path/to/image1.sif" container image on some.host.somewhere.
Connecting to the remote host with VS-Code: F1 > "Connect to Host" > "myimage1~somehost” should now get you a remote VS-Code session running in the container image as well. The same for "myimage2~somehost", "myimage1~otherhost" and "myimage2~otherhost".
Step 3
However, since VS-code reuses remote server instance, that's not sufficient to run multiple container images on the same host at the same time. To get separate (per container) VS-Code server instances the same host, add something like this to your VS-Code preferences:
"remote.SSH.serverInstallPath": {
"myimage1~somehost": "~/.vscode-container/myimage1",
"myimage1~otherhost": "~/.vscode-container/myimage1",
"myimage2~somehost": "~/.vscode-container/myimage2",
"myimage2~otherhost": "~/.vscode-container/myimage2"
}
Request to the VS-Code dev team
Could "remote.SSH.serverInstallPath" be controlled via an environment variable? This would allow us to eliminate all these cumbersome "remote.SSH.serverInstallPath" preferences. The environment variable could be set by a container startup script on the remote side (like the one below) automatically, depending on the selected container image.
Other Container runtimes
To use a different container runtime than Singularity (e.g. Shifter, Charliecloud, etc.), simply replace singularity shell /path/to/image1.sif by the appropriate command for your runtime.
On some systems (e.g. with Shifter at NERSC) you may also need to override $XDG_RUNTIME_DIR, since it's default location may not be writable from within a container instance. In such cases, it's best to use a custom container run-script like
#!/bin/sh
export XDG_RUNTIME_DIR="${TMPDIR:-/tmp}/`whoami`/run"
exec shifter --image="$1"
So in your SSH config, use
RemoteCommand /my/homedir/.local/bin/run_container image_name
I maintain a little container start-script called cenv that handles $XDG_RUNTIME_DIR (and quite a bit more, including some default bind-mounts) automatically for both Singularity and Shifter (contributions welcome).
Tips and tricks
If things don't work, try "Kill server on remote" from VS-Code and reconnect.
You can also try starting over from scratch with brute force: Close the VS-Code remote connection. Then, from an external terminal, kill the remote VS-Code server instance:
$ ssh somehost
$ kill -9 -1
(Will kill all processes you own on the remote host.)
Remove the ~/.vscode-server directory.
Old:
I believe this is still not supported. Refer to this issue: https://github.com/microsoft/vscode-remote-release/issues/3066, and there are also some ideas for potential workarounds in the same link.
I am trying to get the yuma123 open source implementation of a NETCONF Server running on an embedded Linux system.
The NETCONF Server uses sshd, and yuma123 appears to assume that it is the openssh implementation of sshd as it uses the /etc/ssh/sshd_config file.
In particular, the README file in yuma123 states:
Tell sshd to listen on port 830. Add the following 2 lines to /etc/ssh/sshd_config:
Port 830
Subsystem netconf "/usr/sbin/netconf-subsystem --ncxserversockname=830#/tmp/ncxserver.sock"
However, the embedded system currently uses the dropbear cut-down implementation of sshd due to memory constraints, and I am having difficulty getting openssh (together at the same time with yuma123) installed on the embedded system due to the size of the executables, dependant libraries etc.
Can I get/amend the dropbear sshd to give me similar functionality? Can I cut-down the openssh sshd drastically to a small enough size? Any (other) suggestions on a good way forward to resolve this?
According to the dropbear source code, the only subsystem built into the dropbear SSH server is optional support for SFTP, which I'll describe below.
Supporting another subsystem requires making source code changes to dropbear. If that's an option, the code at issue is in the function sessioncommand() in the file svr-chansession.c:
#if DROPBEAR_SFTPSERVER
if ((cmdlen == 4) && strncmp(chansess->cmd, "sftp", 4) == 0) {
m_free(chansess->cmd);
chansess->cmd = m_strdup(SFTPSERVER_PATH);
} else
#endif
{
m_free(chansess->cmd);
return DROPBEAR_FAILURE;
}
Basically, you'd add some code similar to the "sftp" section which checks for your subsystem name and invokes the desired command.
If you don't want to build a custom version of dropbear, then you might be able to make do with a forced command. There are two ways to do this.
If the users of this subsystem will be authenticating with an SSH key, then you could put a "command" directive in the user's authorized_keys file:
command="/usr/sbin/netconf-subsystem..." ssh-rsa AAAAB3NzaC1yc2...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When a client authenticates with the key from this line in the file, then any command, shell or subsystem request from the client will cause dropbear to invoke the listed command instead of the command requested by the client. This is an OpenSSH server feature that's also supported by dropbear.
Alternately, dropbear has a command-line option -c which lets you specify a forced command for all clients:
dropbear -p 830 ... -c '/usr/sbin/netconf-subsystem ...'
Dropbear will invoke the specified command for any client connecting to this dropbear instance. If you want to permit clients to do other things besides running that command, you'd have to run two instances of dropbear, listening on different ports or addresses.
SFTP Subsystem support:
I'll describe this because doesn't seem to be well documented.
If dropbear is compiled with the option DROPBEAR_SFTPSERVER, then dropbear will invoke the command "/usr/libexec/sftp-server" for clients requesting the "sftp" subsystem. For that to work, the administrator would normally build a copy of the OpenSSH sftp-server program from the OpenSSH source code, and install the resulting program as /usr/libexec/sftp-server.
Changing dropbear to run a different command requires altering the dropbear source code and recompiling dropbear.
I am currently trying to code an application for a macOS to control an Arduino. To do this I need to be able to access telnet and send string commands to it. Any ideas on how to do so?
telnet is insecure, inflexible and out of fashion - folks use ssh now. There is no longer even a telnet client in High Sierra.
Create an empty file called ssh in the partition of your SD card called boot to get in the first time. Then ssh in with:
ssh pi#<RASPI-IP-ADDRESS>
and password raspberry.
Then use:
sudo raspi-config
to enable ssh for future boots.
I am not able to SSH to Raspberry Pi 3 from Putty. I can ping the 192.168.137.1 IP address assigned by sharing Internet connection.
The problem I realized that SSH is not enabled by default in Pi3 and saw the posts which suggest to enable SSH by creating 'ssh' file inside /boot folder. I got the SD card which has pre-installed Noobs so when I open SD card it shows only /recovery folder. How to enable SSH in this case ? Please help to resolve it .
Enable SSH like:
documentation
Or start it manually sudo service ssh start - note that manual option will require startup scrip to run at each startup.
Additional settings like port configuration should be done insshd_config. Do it with your favorite editor sudo nano /etc/ssh/sshd_config. Anyway your post should be opened at raspberry forum not at SO...
you can take a look at this thread
How can I get connection with Raspberry without access of its shell?
it mentions about PiBakery which will install rasbian with ssh support. by default ssh is disabled but this might help.
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
Improve this question
Have a RPI2 with latest Jessie Lite Raspbian Jan 2017 with Adafruit Ultimate GPS hat and PPS using info from a post at digitalbarbedwire.com. Easy setup and PPS and all gps commands work great locally.
I am trying to get gpsd to accept incoming requests over the network on port 2947 to export position info (OpenCPN). I edited /etc/default/gpsd to add the -G option GPSD_OPTIONS="-n -G" but external requests are not being allowed. If I stop gpsd (sudo service stop gpsd), and invoke gps in the foreground (/usr/sbin/gpsd -N -n -G /dev/ttyAMA0 /dev/pps0, all works fine! So I am guessing there is a permissions problem starting the gpsd as a daemon, but I haven't figured it out yet. Drivings me nuts!
Any suggestions?
Relevant files:
$ cat /lib/systemd/system/gpsd.socket
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets
[Socket]
ListenStream=/var/run/gpsd.sock
ListenStream=[::1]:2947
ListenStream=0.0.0.1:2947
SocketMode=0600
[Install]
WantedBy=socket
$ cat /etc/default/gpsd
# Default settings for the gpsd init script and the hotplug wrapper.
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"
# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="true"
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/ttyAMA0 /dev/pps0"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-n"
$ cat /lib/systemd/system/gpsd.service
[Unit]
Description=GPS (Global Positioning System) Daemon
Requires=gpsd.socket
# Needed with chrony SOCK refclock
After=chronyd.service
[Service]
EnvironmentFile=-/etc/default/gpsd
ExecStart=/usr/sbin/gpsd -N -G $GPSD_OPTIONS $DEVICES
[Install]
Also=gpsd.socket
Any ideas?
Gpsd is not actually listening on port 2947, systemd is. By default in Debian this is local only. When a request comes in systemd starts gpsd, if necessary, and redirects future requests to the daemon. So giving gpsd the -G parameter will not actually change anything.
You need to add an override for the systemd gpsd.socket unit, and tell it to listen on all addresses:
# /etc/systemd/system/gpsd.socket.d/socket.conf
[Socket]
# First blank ListenStream clears the system defaults
ListenStream=
ListenStream=2947
ListenStream=/var/run/gpsd.sock
Best practice is to put this override file in /etc/systemd/, and not to edit the unit files in /lib/systemd/.
Documentation on the systemd.socket syntax: https://www.freedesktop.org/software/systemd/man/systemd.socket.html
Linux Mint 19, I had to replace 127.0.0.1 with 0.0.0.0, then I could share GPS data on LAN
#/lib/systemd/system/gpsd.socket/gpsd.socket
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets
[Socket]
ListenStream=/var/run/gpsd.sock
ListenStream=[::1]:2947
#ListenStream=127.0.0.1:2947
ListenStream=0.0.0.0:2947
SocketMode=0600
[Install]
WantedBy=sockets.target
Another way to do it is to do a terminal-less SSH session with port forwarding.
For example, let's say you have PC1 running a gpsd service (either via systemd or stand-alone).
From PC2, you can do this:
ssh -N -L 2947:localhost:2947 user#PC1
The -N flag prevents an actual terminal session (no commands executed).
The -L flag means forward port 2947 to localhost 2947.
Now, ssh will not auto-reconnect if for some reason the session is lost or terminated. The work around is to install autossh, available in most linux distro repositories.
You can then use autossh like so:
autossh -N -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -L 2947:localhost:2947 user#PC1
If it works, add -f to let autossh go in background mode.
You can easily run autossh from rc.local or a systemd unit. Doing it this ways means you only have to allow SSH port in (22) and are now passing the gps info via a secure encrypted connection, something that a gpsd socket session alone can't do. Obviously, it helps if you have a key pair setup between PC1 and PC2 as you won't need a password.
You can run on PC2 any of the gpsd tools that come with it as it will appear local to it. API calls from scripts/programs will also work as if port 2947 was actually running gpsd locally.
Look here for more detail on how to use autossh.
After running down all the suggestions including the above, I ended up just following the instructions on the troubleshooting page for gpsd in gitlab, in the last section called "Real World Example". That's the only thing that worked for me.
Install socat
and use this command:
socat TCP4-LISTEN:2948,reuseaddr,fork TCP4:localhost:2947
And use port 2948 over network
You can add this in crontab