search

unixabg / cryptmypi

Project to assist users in building an encrypted raspberry pi
GNU General Public License v3.0
63 stars 20 forks source link

New version4 dev PR #7

Closed splitstrikestream closed 4 years ago

splitstrikestream commented 4 years ago

To my master changed README directing to the official project.

splitstrikestream commented 4 years ago

Complementary answer...

I did not test this latest changes already but will do so in a moment. WIll let you know here if everything works, to save you time.

On the top of the list, I want to create a [optional?] hook that executes a setup script for the machine. As I see, there are tons of things that should not be implemented as hooks, but rather are machine specific configurations. My goal is to be able to have multiple configurations ready for my several needs: a portable kali, a simple drop box, a router, ...

Sure, I would recommend leaving as a hooks for now, but they can be added to a hooks-sample directory as listed in this project https://github.com/unixabg/SteadierState . They would just be optional things that can be included if called, but separate from core operations.

I get it. That is kind of what I've tried to do creating XXXX-optional-... (and XXXX-experimental-...) hooks.

Anyways, my intention with a "setup script hook" would be to allow the definition of a script file in the .conf file, aiming at very specific configurations (that wouldn't make sense have a hook for) as well as allowing flexibility for users to do things that don't already have hooks for. I, for instace, need to clone a few repos, add some of its dirs to the path, and so on...

I do not do iodine, someone else was testing that for the project. I would have to look further in to it but not a priority for me atm.

Not a priority for me either, but I will take a closer look at it.

  1. There is a .vscode dir I shouldn't have commited. It does not break anything, but is an IDE speciffic config.

If not important I will drop.

Done

  1. We have not tested it with any other distros... Packages and etc will differ on them... On top of that, now the project is able to create non encrypted RPi kalis. As a suggestion, it would make more sense to rename the tool/project to kalimypi.

I have considered this in the past, but I always see other use cases, in particular for Debian. I would like to test your code and get to master. After that I am curious to examine a few runs on stock Debian as well.

:+1:

  1. I should change my master README to point to your project as the de-facto, but if I do it now it this changes will automatically make part of this pull request.

Done

I would like to make a run or two with the code in the next-4.x branch (basically your pull request)

Test it with this PR changes so you don't have to do it twice.

Do you want me to fix the tabs and trailing spaces into a new commit?

Yes please. If you can test that would be great also. I am doing a git pull against your master to next-4.x so we should be good.

Done

splitstrikestream commented 4 years ago

I am reviewing possible bugs while testing (running / trying on the RPi).

As each run takes some time, will have to finish this process tomorrow... Will let you know when I finish running all of my personal configs / scenarios successfully.

unixabg commented 4 years ago

Greetings,

I am reviewing possible bugs while testing (running / trying on the RPi).

I am setting up for some runs as well.

As each run takes some time, will have to finish this process tomorrow... Will let you know when I finish running all of my personal configs / scenarios successfully.

ack

Do you do irc? If so I go over to #kali-linux and irc would be better for me than using these threads on PR. Also if you make more changes please do:

pull --rebase

before push. Also I test then unify some things then if works merge to master.

splitstrikestream commented 4 years ago

This PR is closed, so I am creating a new one. Will answer there