SOCKSPEC examples
Closed this issue · 3 comments
Sorry to monopolize you, but my ultimate goal here is to use a socket on the remote machine, rather than the exec:ssh... method shown in the examples. Ideally with the ability to separate the create function locally on the remote for example. I find sockets to be a very complex subject and in this case even more perplexing as I understand that unix domain sockets are meant to be used only on the local machine, as communication occurs within the kernel. No matter the syntax I use on both ends, and I have tried many, I get: error: failed to connect to SOME_MAGIC_SYNTAX: No such file or directory
I wonder if you could elaborate on both the create --listen and output add syntax with a real life example?
Also I notice running netevent create --listen leaves netevent running, is this necessary after the socket is created? Easy enough to get rid of if not. The point of all this is I wish to build it into my initram, so that input devices are available immediately, rather than waiting for the OS to load sshd & friends for example. I was successful in doing this with stable-1 branch, however, only with root permissions on uinput, initram just isn't flexible enough for lots of groups and users, needs pam stuff at least, a mess I'd rather not deal with. I can run netevent create as root, kill netevent, fake out the permissions on the socket though (it would have worked for stable-1 uinput permissions too, I now know).
Oh, incidentally, 1 whole day with the events branch, works perfectly. Just a couple of minor things, I cannot get either daemon quit or daemon info to work, but I see they are not displayed on the daemon help screen either, so perhaps they aren't official yet? I don't believe they worked for me on the master branch either, but don't recall for sure. Anyhow, killall works fine and at least in my simple usage, I already know the info ;)
Thank you.
Well I do comprehend a bit better now. Yes, the create command must remain active. Apparently I'll need to use a tcp socket using netcat or similar. I'll probably have to go with plan B, use root permissions for the quick and short startup, then kill all that and restart with unprivileged setup after OS loads. Onward I plod, but I am interested in your thoughts.
I think you want to read:
Unix sockets are just special files in the file system, and abstract unix sockets are just arbitrary names. I realize the --listen/--connect/--daemonize options can seem a bit much, but it's flexible and allows different ways to set it up (eg. as part of an exec:ssh output or as inetd/systemd.socket unit) and is partially a side effect of the different ways I was setting it up as I initially had quite the ugly shell scripts for v1 ;-)
There are various reasons I haven't actually added network sockets (yet) btw.:
The most important one was that exec allows pretty much everything already: ssh for both authentication and encryption, netcat for simple networking, socat for pretty much everything imaginable ranging from ssl sockets to regular unencrypted networking, to pipes and even to http-proxied CONNECT commands ;-) (socat is the god of sockets...). unix sockets were a natural addition, and with the protocol:... syntax I did plan to also add some networking eventually if somebody wants/needs it, but since it already "looks" a lot like socat syntax I'm not sure it's worth duplicating the feature set.
Which leads me to a question: why do you need this in the initramfs? Because if you want to use it for things like typing in the disk encryption passwords I'd want not only network sockets but also encryption (via openssl or gnutls).
Btw. if you haven't already, I do suggest looking at socat as a more powerful addition/replacement for netcat. Eg. on the daemon: output add foo exec:socat - TCP-CONNECT:1.2.3.4:1337, and on the remote: socat TCP-LISTEN:1337 'exec:netevent create' (for the ability to reconnect to such an instance you'll probably want to start the two separately with socat connecting to a unix socket and netevent using --on-close=accept --duplicates=resume ... (as found in examples/laptop-and-vm-with-systemd/daemon.ne2 I linked on top)
I am learning much more about sockets than I ever thought I might. The haze is beginning to fade, but I'm not ready to write netevent3 yet.
You just solved my last issue though with output add foo exec:socat - TCP-CONNECT:1.2.3.4:1337, that's the magic I've been searching for. I can start the remote independently with netevent create --listen $(socket -sl PORT). And as you point out many different things are possible, no doubt other things would work.
What really threw me off is the unix:/ syntax, I am having difficulty finding much reference to that on the web.
I did see that systemd/daemon.ne2, in fact, I know the netevent github site by heart, but that refers to a virtual machine on the same host, there seems to be quite a difference dealing with unix domain sockets and sockets over TCP, at least to my dim neophyte comprehension.
I have both nc and socat, I understand that socat is nc on steriods. I also have socket, proved handy tonight.
I'm not using encrypted disks on that machine, it's really very simple. I also have an auto-fsck function built in my initram(rd) triggered by finding a /force_fsck file on disk. It then unmounts and checks the rootfs. These arm machines, every one I've ever had, about 5 now, whenever they crash, whatever, the disk gets corrupted, rarely seriously, but needs to be checked. Even power interruption (the only way to shut it down without OS shutdown commands), will cause journal corruption every time. Occasionally fsck wants a "fix this issue (y)", a big hassle when there is no keyboard. I've kept a junk keyboard attached just for that reason, no longer necessary.
And while I was at it, in the past I used a bluetooth keyboard on that machine and a multiboot selection OS, there was no way to choose, the bluetooth drivers came in much later. I'm sure there are other folks with that kind of issue too, so I'll post the setup for all. And also - Just because I can!
I think netevent is very versatile as is, I agree with you. Was just having trouble finding the right incantations due to my lack of knowledge about sockets.
Thanks for the great info, I'll study it more tomorrow. And I think you can close this bug.