Rust on WSL

 Not going to repeat it (assuming it will work for me as well): https://harsimranmaan.medium.com/install-and-setup-rust-development-environment-on-wsl2-dccb4bf63700

POSIX development on windows

 With Windows Subsystem for Linux (WSL for sort) you can do all sorts of amazing things, including developing POSIX compatible code, all in your favorite (?) Windows environment. Let's get to it, it is less complicated than it looks.

Install WSL

It should be as simple as running this from an administrator command line:

wsl --install

If it does not work for you, you may need to tweak your BIOS settings, install windows features, or something else. This article should be a good starting point for your troubleshooting.

I will be using the default (Ubuntu) installation as an example.

If all went well, you can start your linux machine from the cmd line with "wsl" or from the start menu as "Windows Subsystem for Linux". Do it now.

Install linux tools

An example list, tweak it to your taste:

sudo apt install  gcc gdb valgrind make pkg-config doxygen 

Install VS Code and tools

I am 99% sure you have VS code installed already. If not, you can find some resources here.

WSL for VS Code is a funny little beast, unless you are familiar with the split brains approach (some other languages use this as well), it might worth try to look at it here.

Long story short, Remote Development extension pack is all you need to work with your WSL.

C/C++ Extension Pack might also be interesting.

To be continued...

LFTP job management

It is a bit different than default linux job management

Send job to background

putting a job into a background:

• start in background mode, i.e. pget remotefile.big & OR
• start normal mode, then press ctrl + Z

exit - detaches terminal from the session, disconnects from the server
exit - again, exits lftp and sends the job to background

... and get back to it later

ps aux | grep -v grep | grep lftp | awk '{print $1}'  - find the PID for the main lft session

lftp - start lftp

attach <PID> - attach to the terminal of the background session

some more useful commands

jobs - check the status of the running jobs

wait, fg - bring the job to the foreground

kill - kills a bg job, or all of them

Manage SSH public keys with github

This is just another note-to-self post.

Wouldn't be nice to have your publickey stored in someplace where you can import it to .ssh/authorized_keys? Apparently github is a very convenient place for exactly that.

Generate your digital identity (source)

Luckily you only need to do this once.

1. In Git Bash (or your linux machine)
1. ssh-keygen -t rsa -b 4096 -C "your_github_email@example.com
2. Add the public key to github (source):
1. Find your public key file. The default location is ~\.ssh\id_rsa.pub
2. Go to https://github.com/settings/keys and add it ot your keys
3. (optional, Windows & Putty only) Convert public key to putty format (source):
1. Open puttygen, and:
1. Click Conversions/Import key.
2. Navigate to the OpenSSH private key and click Open.
3. Under Actions / Save the generated key, select Save private key.
4. Choose an optional passphrase to protect the private key.
5. Save the private key as id_rsa.ppk.
2. Open putty, and:
1. In Session tab, load the config you want to change
2. Open SSH/Auth, tab, Browse the id_rsa.ppk
3. Back in the session tab, Save the config

Import the key on the server you are connecting

Yes, on all of them

1. On your remote server, you can add the public key like this (tested on ubuntu server): ssh-import-id gh:<github_user_id>

Troubleshooting

(Putty only): make sure your client actually sends in the key. The ky file location stored with the saved session

On the remote server side:

chmod 700 ~/.ssh - to fix permission errors on the folder

chmod 600 ~/.ssh/authorized_keys - to fix permission errors on the file

Alpine Linux install

If you start working on Docker these days it is inevitable to run into Alpine Linux at certain point. It offers 1/10 of the size of a Debian based container (5 mb vs 50 mb), and many application stacks already offer Alpine based image to derive your micro services from. Debian can be slimmed down pretty well and there is a loyal following using it for containers and servers as well.
To try it out I decided to build a VM based on Alpine so I can evaluate it as a container image base.
Adventures in the Alpines so far:

1. There is a pretty good starting guide, with some caveats:
1. use bridged connection instead of nat if you want to see your vm from your host/other machines in the network, and performs better too
2. use the latest-stable url to enable community repository, otherwise you could get some ugly kernel incompatibility errors
2. Minimalist samba install (loosely based on this wiki page)
1. apk add samba
2. mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
3. nano /etc/samba/smb.conf
4. Enter the above to the text editor, save and exit

[global]
workgroup = WORKGROUP
netbios name = server1
security = user
map to guest = Bad User
dns proxy = no

1. Start/enable service
1. rc-update add samba
2. rc-service samba start
2. Enable ssh access
1. nano /etc/ssh/sshd_config
2. #PermitRootLogin prohibit-password => PermitRootLogin yes
3. rc-service sshd restart
3. Docker install is fairly simple
1. apk add docker
2. rc-update add docker boot
3. rc-service docker start
4. Some other utilities to install:
1. apk add git
2. apk add nodejs

CentOS howto V - Custom systemd service

1. nano /etc/systemd/system/cloning-vat.service

[Service]

WorkingDirectory=/home/shared/cloning-vat/

ExecStart=/usr/bin/npm start

Restart=always

StandardOutput=syslog

StandardError=syslog

SyslogIdentifier=cloning-vat

User=nodejs

Group=nodejs

Environment=NODE_ENV=development

[Install]

WantedBy=multi-user.target

1. systemctl daemon-reload
2. systemctl enable cloning-vat
3. systemctl start cloning-vat

CentOS howto IV - Poking holes in security (in a meaningful way)

1. Add an existing service
1. firewall-cmd --permanent --zone=public --add-service=https
2. firewall-cmd --reload
2. Create a new service (to be added as above). In this example we will be using livereload default port 35729
1. firewall-cmd --permanent --new-service=live-reload
2. firewall-cmd --permanent --service=live-reload --set-description="live reload"
3. firewall-cmd --permanent --service=live-reload --set-short="live reload"
4. firewall-cmd --permanent --service=live-reload --add-port=35729/tcp
3. Enabling an application (node.js in this example) to bind ports <1024
1. setcap 'cap_net_bind_service=+ep'/ usr/bin/node