[tor-talk] Scripted installer of Tor and more being worked on at GitHub, ya may want to sit down for this...

[Michael]

Salutations Tor,

I've something special to share with you all; regardless of if you're a node operator, hidden service provider, client or completely new to Tor installation and configurations... in short... a script pack aimed to install and configure the previously listed node types and then a little more.
https://github.com/S0AndS0/Perinoid_Linux_Project

But because this script pack may not work just yet, I've also posted a quick guide at the following link for how to take useful bits of the source code and rewrite variable assignments to positional arguments for specific node requirements.
https://unix.stackexchange.com/a/255023/149903
~ Note the above linked code only covers in detail how to setup a trans-proxied bridge for a Whonix related question but the steps should be similar if an exit node or hidden service is wanted instead. Everything so far is written such that those familiar with 'bash' scripting should be able to read scripted logic without to much effort, and those not so familiar with this scripting language may, with documentation, be able to understand with moderate effort. My hope in contacting you all is that we can start a dialog as to where this script pack should head in future developments and what can be improved upon with the current version.

Readers of this message have permission to take what they wish and make of it what they will so long as links to the repo and relevant [~/info/program_name] links to original code author's documentation are included in your source code as well; because it's polite to the original authors of guides resourced and I've make it easy to copy and past it all. I'm publishing this on GitHub, and other open forums, such that this code maybe taken over if my health again takes my hands away from being a creative force. Nearly every resource used to write this script pack can be found within the repo's [~/info/] directory, nearly every file contains only one function that has clear documentation bellow (commented out with '#' marks) describing what that bit of code is intended to do, what variables are used, and how they are assigned. The configurations and installations for packages are found under directories with the same name, for example Tor installation and configurations are under
[~/functions/tor] and the same for Polipo or Privoxy. And for those wondering where some of the magic is hidden, look no further than [~/functions/shared/] directory as the functions there read things about your distribution and networking; non of which is shared by the way unless you post it somewhere your own self.

The list of things left to do is long for this to be considered finished, this list will be updated as feature requests and bugs are submitted, and hosted within the main [ReadMe.md] file. Anyone who wishes to fork the code's branch may also submit pull requests, I'll happily accept some help, but it'll be up to editors and authors to add themselves to the list of credits in the [~/info/] directory; that is if they wish to make it easy to track contributions.

Note those of you that are browsing the code now while reading this my come across directories and files that are not currently called by the main script, such as [~/functions/whonix/] directory and a few others, these are script parts that have yet to be incorporated and serve as a reminder to myself of where to pick up on each application when coming back to it to make more additions. Some are more fleshed out than others but most are not functional just yet. Additionally there's a directory in the root of the repo named [/scriptlets/] the scripts contained here are for the most part functional but not really needed in the main script runtime.

Here are some example commands to get everyone started;
bash Sandcastle.sh -h=Install_Apt
- Print help documentation on function named "Install_Apt" and exit. Additionally multiple functions maybe inspected before exit via
bash Sandcastle.sh -h=Install_Apt,Arg_checker
~ or via
bash Sandcastle.sh -h='Install_Apt Arg_checker'
~ note the [-h=some_function] is the same as [--help=some_function], all the options written so far support long or short hand ways of asgning values, and most have the ability to parse through lists of values and a few have sub options within.

bash Sandcastle.sh -vf=client_torinstall_vars.sh
- Tor client with DNS server to aid in preventing DNS leaks via variable/configuration file. Note more than one file maybe loaded if you wish to keep things organized that way, just separate files like so [-vf=variable_file_one.sh,variable_file_two.sh,variable_file_three.sh]. The above is much like the following but with less commands to process.
bash Sandcastle.sh -A=tor,privoxy,squid,bind -C=8 -T=client -I=aptget

bash Sandcastle.sh -A=tor,privoxy,squid,bind -C=8 -T=client,service -TST=auth:ssh -I=aptget
-Tor a client plus hidden ssh server that also has Tor auth-tocken required to prevent script bots from easily achieving a connection; will configure two start/stop scripts, one for your client connections [/etc/init.d/tor_client] and one for your ssh server [/etc/init.d/tor_auth_ssh]. You'll end up with start/stop scripts for Tor named [tor_client] and [tor_auth_ssh] under [/etc/init.d/] directory and for Privoxy, Squid and Bind the start/stop scripts' names will be unchanged, however, if previously installed these files will be backed up prior to overwriting.

bash Sandcastle.sh -A=tor,privoxy,squid,bind -C=8 -T=client -OSP=22 -SHN=hidden_ssh_server -SHD=domain.onion -HAC='hidden_auth_token with quotes if spaces are present' -I=aptget
- Tor client plus hidden ssh client to hidden Tor authenticated ssh server made above. Note [-HAC=...] is only required if connecting to an ssh server using Tor and authorization tokens, additionally this may be used to connect to non-[.onion] domains too. Not only will you have a shiny new [tor_client] start/stop script under [/etc/init.d/] directory, you'll also have a custom [ssh_config] made under [/home/${USER}/.ssh/] directory (the user variable is set by [ : ${USER?} ] quarry near the beginning of script run time) and as always original files if present will be backed up.

bash Sandcastle.sh -A=tor,polipo -T=bridge -TBT=private -Lipv4=192.168.1.5 -B=Bridge_nickname -I=aptget
- Tor bridge for local NAT, trans-proxy hotspot, or in Whonix terms "gateway" on separate hardware. Note I'm still working out how best to implement internal NAT routing for assigning client IP addresses, in other words "some assembly required" to get this part working.

bash Sandcastle.sh -A=tor -T=bridge -TBT=public,authoritative -Eipv4=1.2.3.4 -B=Bridge_nickname -I=aptget
- Tor bridge for public use plus authoritative mirror for network traffic queries. Note if you do not supply [-Eipv4=...] and it is needed you will be prompted for it, and if you leave that prompt blank then OpenDNS will be queried for the needed information. Additionally I'm working on IP version 6 options such that [-Eipv6=...] maybe recognized in future revisions.

bash Sandcastle.sh -A=tor -T=exit -ipv6=yes -Eipv4=1.2.3.4 -Eipv6=f:8:::9:1 -E=Exit_nickname -I=aptget
- Tor exit (restrictive policies) with IP version 6 enabled. Note this is where things are even less finished and I'll be fixing on the next series of code pushes. Mostly you'll want to have already installed and hardened the web server used to push exit notices to the quizzical that connect back to your exit's IP address; ie sysadmins wondering why you seem so interested in their IP address.

Notable features and how to find their related code blocks;

- Already detects if running within chroot Linux inside Android but not all required permissions may have been set for the [aid_inet] user/group. To find how this is done refer to the function within [~/functions/shared/check_host_enviroment.sh] for Android chroot detection and [~/functions/shared/fix_android_inet.sh] for Android permissions additions. I've tested this with two methods of running Linux on root enabled Android but more testing of other apps would be helpful in assuring it works across all devices and chroot/shroot methods.

- Already detects if arguments have been passed via [--var-file=/some/configs.sh] or [--arg1=option1] and both may be mixed, see [~/functions/shared/parse_varfile_load.sh] for where script expects to find configuration files and see [~/functions/shared/arg_checker.sh] for how arguments are processed in general, however the order in which you pass arguments vs. config files does matter if using both.

- Reports and log errors if any as well as print related help documentation for the section that errors where encountered, see [~/functions/shared/parse_help.sh] for how help docs are auto-pulled from erroring function and [~/functions/shared/error_generator.sh] for how error logs are written. 

- Does not touch currently configured torrc files or any configuration file without first backing up the original, additionally for Tor specifically do to the installation methods used to activate the various options, this script shouldn't have to touch your default files if you've already installed and configured Tor; see [-/functions/shared/overwrite_config_checker.sh] and [~/functions/shared/overwrite_init_checker.sh] for how configurations are preserved and for Tor specifically see [~/functions/tor/lib_activations/activate_torrc_nonclient.sh] and [~/functions/tor/lib_activations/activate_torrc_client.sh] for how installation process is manipulated to be nondestructive to previously installed Tor services. Other packages that require it will have a similar directory and script naming convention in their related package directories. This means that care should be taken to not run Tor over Tor and that the default Tor start/stop script should be deactivated if enabled on user login
or system boot if the new configurations are preferred.

- Upon successful installation the variables used will be output to a custom configuration file such that once a user figures out their own perfect settings this custom configuration file can be used to quickly rebuild the same or very similar configurations on another device, see [~/functions/shared/output_variables_file.sh] for where these are saved by default. Additionally these configuration files, if scrubbed of personal info, maybe shared with others such that they can replicate the same kind of node setup.

- Additional features such as adding your own functions from outside the script's working directory is also permitted as well as loading available functions without calling them right away. The [arg_checker.sh] function and main function within [Sandcastle.sh] file handle how this is preformed and is enabled so that future editors may load modifications or new features, for initial tests, without having to save these mods inside the script's working directory. In other words "plugins" are allowed from the first commit on GitHub; this also allows for authors of new features to keep their code separate from the main project, for example privet GitHub repos if so desired.

Thank all you for your time and attention, I know this was long to read but hopefully after checking out what I've shared you'll see it as time well spent. Feel free to ask questions, I've attempted to cover most of the foreseeable ones, and I'll get back to you as time and health allows. I will be testing and debugging this on various VPS instances and physical devices that I've at my disposal over the coming days and look forward to your responses.