I have 2 pwnagotchis.
i set one to 10.0.0.3 and the other to 10.0.0.4, so ssh-the keys don't collide.
but after the auto-update, the IP was back at 10.0.0.2
i adapted the backup-script to save the usb0-configuration, but that was only good when i had to download a new image for each update.
but now with auto-update, it would be more convenient to just keep the changed file.
and what if we need to change those files? i'm sorry those are system files, you either backup them manually and restore or you lose them during updates ... we need to be able to update them as needed.
Couldn't we get some kind of blacklist and make it the users responsibility to check now and then if the files have to be updated? I really think, that this will affect multiple users and a workaround really would help.
i'll reopen this as a reminder to find a better solution 馃憤
ok, why not treat ip as configurable option just as (host)name?
sounds like a pita if the user can exclude files from the update process. Like, something gets fixed, but user open issues cuz the excluded the file containing the fix. So this doesn't sounds like a good solution to me
sounds like a pita if the user can exclude files from the update process
yeah that will cause unsupportable chaos. but we're fucking with system files anyway (hostname), so why not fuck with it some more, e.g., interface configuration or timezone.
okay, how about a different solution:
each pwnagotchi of a herd or of a pwning, gets an index via config.yml
and the index becomes the 4th octet of the IP
this although limits a pwning to 255 pwnagotchis ( wanna see that :) )
doesn't solve the problem as we still need to be able to update system files ... i think the only clean solution would be to parse the network files to get the current ip, replace the files with the new ones and restore the changes if the IP is different than the default. This should happen in setup.py
after thinking about this, i've realized that my solution just doesn't make any sense: if the user customized the file and we generate a new file with the customizations, this is equivalent to just not overwriting the file to begin with ... so for now, netowork interface configs only get installed if not present, otherwise they are just skipped ... if in the future we'll need to force-update those files for some reason then we can just change that logic in the setup.py 馃憤
Kwl thx
Most helpful comment
after thinking about this, i've realized that my solution just doesn't make any sense: if the user customized the file and we generate a new file with the customizations, this is equivalent to just not overwriting the file to begin with ... so for now, netowork interface configs only get installed if not present, otherwise they are just skipped ... if in the future we'll need to force-update those files for some reason then we can just change that logic in the setup.py 馃憤