ee uninstall option

[anantshri]

There should be an option if someone wants to completly remove ee from the system.

You might want to warn them but let the user have an option to remove ee completely.

[joseph-jalbert]

Check this out: https://rtcamp.com/easyengine/docs/commands/system/ Found here: #272

[MattyLB]

+1 (including all stacks ee installed)
On Apr 23, 2015 11:35 AM, "Joseph Jalbert" notifications@github.com wrote:

+1

—
Reply to this email directly or view it on GitHub
#488 (comment).

[rahul286]

Can anyone please write synopsis for uninstall process?

Some questions we need to answer:

1. What will happen to mysql (data) when we install mysql server?
2. What will happen to website files if we need to delete /var/www?
3. What will happen to nginx, php, mysql and other config files?
4. If all sites' files and database need to be deleted then why not recreate/format VPS/dedicated server?

Basically, I want to know what a user expects afte easyengine is uninstalled. Since I never need to uninstall easyengine, I find this case harder to imagine.

Uninstall coding is not big deal. We already have commands like ee stack purge and also ee site update-all to deal with all sites. We can reuse there code to remove everything from server. But again need to be removed and what need to left behind?

[ugommirikwe]

I think it's unethical to not provide an easy way for a program to be uninstalled, having provided an easy way for it to be installed in the first place. Only malware act like that :-(

I have had to wipe the entire OS just because it seemed like EE was all over the system and buried deep. Horrible!!!

[rahul286]

@ugommirikwe Thanks for comparing EasyEngine to malware. BTW EE codes are open source so can you please care to point out what malware like activity EE does?

Also, did you care to check my comment above your comment? #488 (comment)

If you can't answer questions I asked in my comment, do not expect us to work on this.

We have more important things to take care. So anyone who needs this badly can send pull-request or atleast answer #488 (comment)

Sorry but I need to know what people expect when they wish to run ee uninstall!

[rahul286]

@anantshri as you started this, please answer #488 (comment)

[rahul286]

@joseph-jalbert ee system remove will remove all packages like nginx, php, mysql EE installs. EE code remains on server itself.

[rahul286]

@MattyLB if EE uninstall need to remove all stacks installed, what will happen to sites? They should simply become unreachable or deleted as well?

[MattyLB]

OPTION 1:
as long as we could have all of our site-specific config files,
certificates and content reside within the /var/www/example.com/...
directory tree, those files wouldn't need to be touched.

upon re-installing ee (to fix an issue caused by upgrade, corrupted main
config, file or otherwise) those would be replaced independently of any
existing sites.

when the reinstall of ee is completed satisfactorily, I believe the best
way to "reactivate" the site(s) in /var/www/... is to run a script like "ee
site discover --enable --prompt --etc" so we can choose to reactivate all
existing sites or be prompted to choose which ones to enable. Each site
could have a simple manifest file that tells ee exactly what needs to be
configured for the site, eg. db user & pw, hhvm, nginx, pagespeed, etc.

---

OPTION 2:
if that can't be done, a simple warning to backup our site data would
suffice - because in all honestly - our only alternative when we run into a
major malfunction is to create a new instance or refresh the server anyway.
:)

On Fri, May 1, 2015 at 10:16 AM, Rahul Bansal notifications@github.com
wrote:

@MattyLB https://github.com/MattyLB if EE install removes all stacks
installed, what will happen to sites? They should simply become unreachable
or deleted as well?

—
Reply to this email directly or view it on GitHub
#488 (comment).

[rahul286]

@MattyLB Uninstalling and reinstalling are different things. EE installation expects a clean system. Not even traces of old EE system are handled as of now. So Option 1 will be a lot of work.

About option 2: we have some other plan in pipeline which might help here. There will be a command to move all EE sites from one EE server to another EE server seamlessly.

[MattyLB]

+1 - that would be a big help. In my particular case, I use AWS and while
it's easy enough to simply create a new EC2 instance, there is a lot of
work to the get my sites back up and certificates placed, etc. so the
migration method you speak of would be a great help! :)

On Fri, May 1, 2015 at 11:07 AM, Rahul Bansal notifications@github.com
wrote:

@MattyLB https://github.com/MattyLB Uninstalling and reinstalling are
different things. EE installation expects a clean system. Not even traces
of old EE system are handled as of now. So Option 1 will be a lot of work.

About option 2: we have some other plan in pipeline which might help
here. There will be a command to move all EE sites from one EE server to
another EE server seamlessly.

—
Reply to this email directly or view it on GitHub
#488 (comment).

[MattyLB]

One of the reasons this is of interest to me is when issue like this most
recent one occur that happened after upgrading from 3.1.0 to 3.1.2...

ee site create xxxxxx.com --wpfc --hhvm --pagespeed

Adding repository for MySQL, please wait...
Updating apt-cache, please wait...
Installing packages, please wait...
Reload : mysql [Failed]
Setting up NGINX configuration [Done]
Setting up webroot [Done]
Downloading Wordpress [Done]
Setting up database (2003, "Can't connect to MySQL server on
'localhost' (111)")

so I tried this ...

root@ip-172-31-27-174:~# ee stack install
Nginx already installed
PHP already installed
HHVM already installed
Postfix is already installed
WP-CLI is already installed
Adding repository for MySQL, please wait...
Updating apt-cache, please wait...
Installing packages, please wait...
Downloading phpMyAdmin [Done]
Downloading Adminer [Done]
Downloading phpMemcachedAdmin [Done]
Downloading clean.php [Done]
Downloading opcache.php [Done]
Downloading Opgui [Done]
Downloading OCP.php [Done]
Downloading Webgrind [Done]
Downloading pt-query-advisor [Done]
Downloading Anemometer [Done]
Reload : mysql [Failed]
(2003, "Can't connect to MySQL server on 'localhost' (111)")

now my only solution is to go into AWS, create a new EC2 instance and
"hope" this doesn't happen again. It becomes a pain, which is why a method
to start from scratch (eg. uninstall EE and any stacks installed by EE
might be an easier way for people facing the same issues).

On Fri, May 1, 2015 at 11:15 AM, Matt Brummett mattbrummett@gmail.com
wrote:

+1 - that would be a big help. In my particular case, I use AWS and while
it's easy enough to simply create a new EC2 instance, there is a lot of
work to the get my sites back up and certificates placed, etc. so the
migration method you speak of would be a great help! :)

On Fri, May 1, 2015 at 11:07 AM, Rahul Bansal notifications@github.com
wrote:

@MattyLB https://github.com/MattyLB Uninstalling and reinstalling are
different things. EE installation expects a clean system. Not even traces
of old EE system are handled as of now. So Option 1 will be a lot of work.

About option 2: we have some other plan in pipeline which might help
here. There will be a command to move all EE sites from one EE server to
another EE server seamlessly.

—
Reply to this email directly or view it on GitHub
#488 (comment).

[anantshri]

hey @rahul286, kept delaying this message coz i thought this need more consideration then my initial comment. So here are couple of scenario's i can think off.

1. Considering EE as just yet another software, just like we have an installation option, we should have uninstall option. one case in consideration. a user installed ee as per instructions but due to one or the other reason (in my case custom webroot location #489) so he is stopped in mid way or rather at the start. What is the safe way to remove all traces of ee as user has not even started using it but decided not to use it anymore. The reason i ask specifically for this option is that user is left in a confused state at this point that whether ee has caused any change or not.

2. Consider at one point in usage the user decides that they don't want this tool. removing stacks is one thing what about custom config's added by ee how can we ensure all those config based on say a user input is either nuked or retained. may be we are already doing it or we need to do a backup of old config and restore when person say remove ee.

3. as for the question why not a new instance why remove it. Multiple reason's including the fact that ee might be part of hybrid environment where other configurations would take time even if that means running a vagrant + ansible job list but still time taken to rebuild stack.

However i agree with you that its not easy to decide what to keep and what to remove. Here i would suggest we make backup of all configuration file that we touch during the life cycle of ee at the time of installation and if asked to uninstall ask user if they want config to be reverted. However an edge case would be if user has tampered with config but still want to retain his custom stuff. in that case i would suggest (if we are not doing that already) to mark sections added by ee as seperate may be how wordpress keeps sections in .htaccess. with a warning don't tempare here it will be overwritten. and use that as pointers to the section to be nuked.

I hope this long rand makes some sense.

[MattyLB]

In regards to the second paragraph of @Anant's point #3, this is what I
meant by creating a manifest for each site that keeps track of site
specific services, config changes, WP settings, DB settings, certificate
locations etc, and it would reside in the /var/www site folder that
wouldn't need to be deleted by the ee uninstaller. It could then be
referenced if we installed ee again to bring the site(s) back up with
current ee features, stacks and base configs.

On Friday, May 1, 2015, Anant Shrivastava notifications@github.com wrote:

hey @rahul286 https://github.com/rahul286, kept delaying this message
coz i thought this need more consideration then my initial comment. So here
are couple of scenario's i can think off.

1. Considering EE as just yet another software, just like we have an
   installation option, we should have uninstall option. one case in
   consideration. a user installed ee as per instructions but due to one or
   the other reason (in my case custom webroot location #489
   custom webroot location #489) so he is stopped in
   mid way or rather at the start. What is the safe way to remove all traces
   of ee as user has not even started using it but decided not to use it
   anymore.

2. Consider at one point in usage the user decides that they don't want
   this tool. removing stacks is one thing what about custom config's added by
   ee how can we ensure all those config based on say a user input is either
   nuked or retained. may be we are already doing it or we need to do a backup
   of old config and restore when person say remove ee.

3. as for the question why not a new instance why remove it. Multiple
   reason's including the fact that ee might be part of hybrid environment
   where other configurations would take time even if that means running a
   vagrant + ansible job list but still time taken to rebuild stack.

However i agree with you that its not easy to decide what to keep and what
to remove. Here i would suggest we make backup of all configuration file
that we touch during the life cycle of ee at the time of installation and
if asked to uninstall ask user if they want config to be reverted. However
an edge case would be if user has tampered with config but still want to
retain his custom stuff. in that case i would suggest (if we are not doing
that already) to mark sections added by ee as seperate may be how wordpress
keeps sections in .htaccess. with a warning don't tempare here it will be
overwritten. and use that as pointers to the section to be nuked.

I hope this long rand makes some sense.

—
Reply to this email directly or view it on GitHub
#488 (comment).

[rahul286]

It could then be referenced if we installed ee again to bring the site(s) back up with current ee features, stacks and base configs.

Anything in this direction will take huge amount of time. Currently we do not have a big team to purse something like this. Specially for uninstallation process.

@ALL

Here is what we are thinking as of now:

-[ ] ee uninstall => display contextual help
-[ ] ee uninstall --stack => removes EE + all packages installed
-[ ] ee uninstall --site => removes EE + all sites created (files + db)
-[ ] ee uninstall --site --stack => removes EE + all packages installed + all sites created (files + db)
-[ ] ee uninstall --all => alias to ee uninstall --site --stack

ee uninstall will need some sort of security. I am thinking of few way like:

1. Forcing ee config to have a line like uninstall = true
2. Prompting for confirmation (remote uninstall will not work unless we provide command line --force switch)
3. Using some ASCII generation logic to emulate CAPTCHA like thing.

A different option we are thinking of is to maintain an external shell script. If anybody want to uninstall easyengine they can download and run that script on EE server.

By the way, WordPress and many other softwares do not provide any "uninstaller" and that doesn't make them malware. So "uninstaller" is must is not enough reason to code one.

I am concerned that if a server gets hacked, attacker can wipe everything out very easily by running ee uninstall command! I am aware, attacker can do same damage in absence of this command as well.

Overall, this issue has lowest priority for us. So unless I am 100% sure that ee uninstall won't result in accidental data loss, we won't add it.