Face Thumb

@UnfortunateShort @KarnaSubarna And you’ll want to audit the client code of the fork, including dependencies and make sure it is keeping up to date with official development for security patches. And Signal may try to break the interoperability at some point in the future.

@UnfortunateShort @KarnaSubarna I think you are right about the official client, they really want to own the service so you can only connect to their decentralized service via their centralized servers 🙄 I haven’t done it, but I think you can run your own client, either modifying and building it yourself, or surely one of the existing forks can connect to arbitrary servers? But anyone who wants to use your server will have to also use one of the forks.

@balder1991 @Lembot_0004 “Working on electronics in your parents’ garage? What are you, some kind of terrorist?!?”

@Cyber Bash also seems to default to only writing out the history entries when you cleanly exit, so I’ve definitely got gaps in my history when I killed a terminal or SSH session. When I leave work I do a quick “history -a” to append new entries that haven’t been written out yet. Some people modify their bash prompt so that it writes each entry out instantly which I haven’t done, but I think it would be a saner default.

@Cyber Yeah the bash defaults are incredibly limited by default, something like 1000 entries, 2000 bytes. I always make those something like 100,000 and 1MB. So the defaults can definitely bite you on an existing system, it may not have stored every command.
https://superuser.com/a/664061

@beerclue Exactly. You can take wiki bash instructions on how a system was set up and translate it to ansible, or back again. The ansible modules are python, but theoretically you could make a bash implementation that just calls dnf/systemctl/etc. directly, like a sys admin would have done.

@Cyber If you have some old wiki notes on how the system was setup originallythen it night be easier to ignore the current system and translate the wiki instructions into ansible. Still manual, but easier than reverse engineering. Another thing you can look at is bash history. Apart from backing up/cloning the system before you start I would also get a copy of the bash history for the various users and add it to a wiki or issue too. It will be useful.

@Cyber Yeah it’s gonna be pretty manual as others have mentioned. Some areas to look at:
- Filesystem provisioning, mounts, etc.
- Packages
- Users, groups
- Time zone, locale language, time format etc.
- /etc/
- /root/ and /home/
- SSH settings
- Services
- Cron jobs/systemd timers

There is a bit of overlap between some of those categories. Some bits are going to see more or less use on VMs vs physical. And remember that in ansible there are built in modules for a lot of functionality.