Regarding yesterday's BD security release, I noticed that @jenlampton posted on FB about having a spreadsheet ready, and then later about letting the update madness begin :)
That made me wonder, how do people have Backdrop setup? I thought it might be nice to explain our setups for the benefit of others, and to maybe learn different/better ways of doing things...
I'll start: I have a VPS server on which I've installed Ubuntu, Apache, mySQL, phpMyAdmin, etc. Backdrop is installed in the public root directory, and I use multisites for the 5 or 6 BD sites I run. I don't do the whole development/testing/production thing (never really saw a need, especially since I build mainly small sites for small organisations), so I update everything live. I have nightly backups of both the server (through my VPS host) and websites files and databases (custom bash scripts I've written).
So for me, updating Backdrop is simply a matter of unzipping the new version, copying over the new /core directory, running `drush cc all` (on all sites automatically via a Drush script) and then cleaning up the zip file.
I'd love to hear what others do, if there's things I can do better/more easily/securely, and am happy to share more info about my setup if anyone's interested.
Comments
Thanks for posting this info on your site setup for backdrop! In my case, I have Backdrop simply installed on a shared hosting server, and I use ftp to do the updates. Absolutely nothing techno-fancy. That's what I like about it. I would prefer to spend my time working on the content of my web site, rather than the convoluted esoterics of composer, etc. The only thing I put extended time in was the CSS, trying to tweak the layout...
This topic is interesting and useful, thank you.
My case is different. I am not a programmer, a computer or a network specialist, I have been working for 26 years with graphic design and prepress of books, magazines, advertising materials etc.
I have a good knowledge of HTML and CSS, some basic notions of PHP and I do not use ready-made themes and layouts but I develop them myself for both Drupal and Backdrop.
I'm self-taught in everything related to site development. The last 10-12 years I have done over 120 sites, currently I maintain over 60, of them 10-15 with Backdrop, one with Wordpress most of the others with Drupal 7 and only a few with Drupal 6. I will definitely not use Drupal 8.
I am not able to install and support my own web server (also to work with Git, Drush, Composer etc) and I use shared hosting with a reseller account, which allows me to create separate hosting accounts for any site I am developing or supporting.
That's why I don't use multisite, even more - my hosting provider disagrees in one hosting account to have multiple domains unless they have the same owner/company.
Another reason is the different life cycle of each site and the access of users to it.
I have clients with almost full access to the site and hosting accounts, who can even install modules and others where I am the only one user in the site.
I don't think it is good idea to give my clients access do hosting account with many other sites that are not theirs.
It happens to transfer the site along with its hosting account to another admin. Or it happens to me to be transferred site with a hosting account, developed by another developer.
And I have sites in different hosting providers and often I am not the owner of the hosting account, but only have access to it temporary.
Some old sites that are not updated with new content I often convert to static HTML sites and save Drupal or BD installation on a local server or backup archive for possible future work and development. This also eliminates the need to update them for security updates.
For all these reasons I do not use a multisites but separate hosting account for each site.
And when I need to update the security release I really do have a lot of work to update each site separately (I work via FTP and cPanel with hosting accounts).
But it is not so scary, I update one site for 10-15 minutes- including backing up the site before and after the update.
During the last Drupal (March 2018) security release, I had several Drupal sites hacked before I could manage to upgrade them. Nothing serious, just an unknown new user "Alex" registered on the site 48 years ago!
I recovered them from backups.
To protect against such attacks on sites that I have not managed to update on time I use (in Drupal) several useful modules that I would like to see in Backdrop too (some already have Backdrop versions):
backup_migrate - for a backup of the site on schedule, keeping the last few months backups of DB and files
md5check - tells me when core or modules file is changed on cron run
rules - notify me when there is a new user's registration not done by me; have plans to make rules notify me of md5check records in system log
access_filter - to grant access to important admin pages only to my IP address
secure_permissions - hides permissions and role admin pages
userone - hides User 1 and block access to its profile
restrict_by_ip - to prevent access to all admin pages of the site that is not yet updated with security release
When it is possible I deactivate or delete Administrator role at all and block User 1 manually editing user table of database via phpMyadmin.
I'm not sure how much these measures are really secure, but I guess it's better with them than without them.
@amilenkov you can add you module port requests here https://github.com/backdrop-ops/contrib/issues
--
For personal sites I use git repos and deploy with BeanstalkApp. It's pretty easy and don't need to ftp then. Nothing special about the hosts. No staging or dev sites and no multidev. At work we host Drupal, WordPress and Backdrop. We also use Beanstalk, except for WordPress sites which usually have auto-update enabled. We have nightly backups