[ubuntu-uk] Automating find and replace

Colin Law clanlaw at gmail.com
Wed Sep 17 15:03:37 UTC 2014


On 17 September 2014 14:08, Gareth France <gareth.france at gmail.com> wrote:
> I understand. In which case the big issue would be weeding out old redundant
> files and ensuring no hidden files exist from this recent hack before
> creating this system.

I did say it did not help you in your current predicament, but may
help in the future.  Don't worry about weeding out redundant files,
you can delete them after you setup the system, then if you later
realise - oops that wasn't redundant at all - then you can easily
resurrect them.  In fact if you can afford to take a day out to set
the system up then there is an argument for starting immediately,
before de-hacking.  Then if your de-hacking goes awry in ways that are
not immediately obvious, then again you have the history in the
archive.

Colin

>
> On 17 Sep 2014 14:01, "Daniel Llewellyn" <diddledan at gmail.com> wrote:
>>
>> On 17 September 2014 08:25, Gareth France <gareth.france at gmail.com> wrote:
>> > Sounds great. My backups are stored on a hard drive here so can't be
>> > compromised but I'd love to find a way to automate it. I'll look into
>> > this
>> > later.
>>
>> I think the point that Colin is trying to convey is that
>> version-control is NOT a backup strategy. version-control sits BEFORE
>> the deployment to the live site and stores every change made to every
>> file in the site to create a canonical "golden master" history. You
>> then mint your live site as a copy of the version-controlled files.
>> This will then allow you to immediately determine whether files have
>> been modified since deployment, which files they are, and how they're
>> modified.
>>
>> With a backup you are reliant on schedule and spotting the problem
>> before it makes its way into your entire history of backups (unless
>> you keep backups till the end of time). With a backup you also need to
>> restore each archive in-turn until you find one that doesn't have the
>> offending code. This is time-consuming! And you have already
>> highlighted the problem of backups not accounting for changes made
>> since the backup was taken. VCS solves that.
>>
>> Version control allows you to immediately isolate the offending code
>> and excise it by either rolling-back the commit that added it (in the
>> case your vcs was hacked in addition to your live site) or just
>> re-deploying your latest golden master over-the-top of the current
>> infected live site (in the case your VCS is still secure).
>>
>> --
>> Daniel Llewellyn
>>
>> --
>> ubuntu-uk at lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-uk
>> https://wiki.ubuntu.com/UKTeam/
>
>
> --
> ubuntu-uk at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-uk
> https://wiki.ubuntu.com/UKTeam/
>



More information about the ubuntu-uk mailing list