project flow and wireguard setup

[xancoder]

We worked on this project for a while and tried to make it fit for all linux
distributions including Raspberry Pi OS. Some changes would improve
accessibility and simplicity of the project. Please find those suggested
changes below:

project flow

Problem:
In the original project, it was necessary to complete multiple
steps to set up the project:

• running make install command in project folder
• editing the file afterwards (changes wouldn't be applied to the
  initramfs otherwise)
• finally building the initramfs

In our opinion, running make install this early in the setup process
complicates the entire process, seeing as how it is then necessary to go to
several different locations within the filesystem to successfully edit the
files.
This requires extensive knowledge about the filesystem and the configuration
process.
It also made the debugging a lot harder, because there is no single point
of failure, and there could be multiple locations where you could break
something during the configuration stage.

To summarize, the main problem we see is that right now, the files are
being distributed and final edits need to be made to the various locations
to make it work.

Proposed solution:
We refactored the folder structure inside the project folder and separated
config files from logic files and initramfs files.

├── configs
│   ├── config
│   ├── pre_shared_key
│   └── private_key
├── initramfs
│   ├── hooks
│   └── init-*
├── scripts
│   └── build_wg_setconf.sh
├── package.json
├── Makefile
└── README.md

The idea is to make all the files available in the downloaded project
folder, edit them there and then distribute them all from the project
folder with a single command (No changes in later stages needed). This
would allow multiple configurations to be maintained by simply copying them
into one folder.

With that, we would also apply the rule of three:
download / configure / make install

The steps needed to complete setting up the project would now be:

• downloading the repo
• configuring the files inside the configs folder
• executing the make install command (at this point it is no longer
  necessary to edit any further configs - which means no searching through
  the filesystem)
• executing the make build_initramfs / make build_initramfs_rpi command

In our opinion, this would simplify the setup process and make it easier to
execute for beginners.

wireguard setup

We would also like to address some specific issues that might require
modification. Please find details on these below:

wg set

The command wg set didn't seem to work on the Raspberry Pi, so we employed
the command wg setconf instead of a previously created configuration file.
This config-file is auto-generated by the script after employing the changes
we described above.

wg conf file

As we just mentioned, we worked to simplify some parts of the script. This
lead to the effect that you'd only need to edit a single config-file in case
you made a typo with the keyfiles.

If the system fails during boot and falls back into the initramsfs shell,
this part is important. This facilitates debugging to a great degree.

date compare

We implement a check due to issue #21 in the initramfs/init-premount
script.

You can review our work here:

https://github.com/xancoder/wireguard-initramfs/tree/project-structure

If you like our work, we could make a pull request in your repo to support this
project.

[r-pufky]

Thank you for all this work, and submitting this as a bug -- please tag pull requests with this bug to keep all the work in one logical issue to track the changes.

Reviewed the proposed changes and they make sense; with the exception that we should allow a migration path for existing installations to move to the new structure automatically (essentially detecting old structure and migrating it in place; which will allow for users to upgrade versions.)

[almereyda]

The PR #25 now also contains a migration script and could be ready for intake.

@xancoder would you have the capacity to rebase on top of #19 and integrate the suggested changes from there along the way?

To me it seems helpful to coordinate with @omkhar's work and aid with how those changes could be applied either on top of #25, or the other way around in one go, as suggested above.

[xancoder]

The pull request #26 was merged very quickly.

@r-pufky, many thanks for your trust and the review effort.

I'm happy to help, and I really appreciate clean and organized repositories. ;-)

For this reason, just two small notes:

@r-pufky, there is still the orphaned branch presharedkey
@omkhar, perhaps you could find some time to clean up the open pull requests.

With this, I would like to close this issue. Thanks again.