Uninstalling script?

[sergeiwaigant]

I plan implement your scripts in our cross-account environment so that I can just install the policys and roles using a cloud formation stack in the service catalog.
After that the users should have the option to download the install.sh script from AWS S3 and use this functionallity when they need it.

It would be cool if there will be an uninstalling script for revert all to basic if they dont need it anymore.

[michaelwittig]

Hi @sergeiwaigant
I labeled this issue as a feature request

[KusabiSensei]

I'll put a brain dump on my fork. I've been through the install.sh enough I should be able to invert it's behavior.

[KusabiSensei]

Brain dump of an uninstall script. I haven't tested this at all, so please exercise caution if actually using this.

I'm currently backed up at work with other things, but maybe I'll be able to test this over the weekend.

https://github.com/KusabiSensei/aws-ec2-ssh/blob/feature/uninstall/uninstall.sh

[michaelwittig]

We have a very limited uninstall in the RPM. It runs:

sed -i 's:AuthorizedKeysCommand /usr/bin/authorized_keys_command.sh:#AuthorizedKeysCommand none:g' /etc/ssh/sshd_config
sed -i 's:AuthorizedKeysCommandUser nobody:#AuthorizedKeysCommandUser nobody:g' /etc/ssh/sshd_config
/etc/init.d/sshd restart

As I can see, you also revert the sshd_config and you use the improved sshd restart that works cross OS. You also revert the changes to SELinux.

Should we delete all the users by default, or only delete them when a specific flag is used?

[KusabiSensei]

By default, the users don't have assigned passwords when they are created (because the goal is to use key authentication), so if you leave them there, you'd have to put some other authentication method in place if you wanted to access them.

I suspect that it would depend upon what it is felt 'owned' the users, as objects in the system. If they are owned by IAM, even as local users on the system, then I'd vote for removing them, as the local account is just an ephemeral mirror of the IAM object. Plus, I feel as if data storage should be done outside of individual instances, rather in S3 or EBS/EFS (likely with a UID squash mapping in the case of EBS or EFS, or some other UID solution).

I don't really have strong feeling either way, but the only thing that we would have control over with dpkg/apt is determining whether or not we purge declared configuration files. Other things we don't have control over (installed files are removed). "User Data" (the user accounts in our case) is something we can do either way, but my feeling is that if we leave accounts and /home directories when removing the package, that could be a big mess dropped in the lap of the user.

A good compromise would be not automatically removing them, but having the post removal script echo out something to the effect of:

We've removed the installed scripts, and the hooks in sshd_config. Any synchronized users and data that were created by them will need to be resolved manually.

I'm open to other suggestions.

[russCompass]

I've been using these commands on ubuntu 14 when we needed to remove for testing.

rm -f /etc/cron.d/import_users
sed -i.bak '/^AuthorizedKeysCommand/d' /etc/ssh/sshd_config
/etc/init.d/ssh restart