[CentOS] Upgrade from 5.6 => 5.7

Thu Sep 15 18:36:23 UTC 2011
Always Learning <centos at u61.u22.net>

On Fri, 2011-09-16 at 01:58 +0800, Emmanuel Noobadmin wrote:

> On 9/16/11, Always Learning <centos at u61.u22.net> wrote:

> But wouldn't an added layer of safety be better?

Yes of course.

> After all, there could be race conditions where two or more users could
> cause the application to pass the transaction to the database, which
>  results in more than the allowed amount being transacted because the
>  individual values were valid when the application checked.

Record locking should prevent that.

> > In most circumstances, instead of entering anonymous un-meaningful
> > digits to identify customers, look-ups are done with postal code or
> > partial address match or partial organisation name match or partial
> > telephone number match etc. I love easy-to-use user-friendly systems.
> 
> Which is where AJAX comes in. Typing in a partial address or postal
> code brings up, almost instantly on LAN environment, matches without
> having to go to a search page or equivalent.

No real different between an Ajax screen and a normal HTML screen (with
CSS) showing the matches.

> > I use the SQL privileges for tables and enable only the SQL verbs
> > required by a user. I certainly do not want a user being able to 'drop'
> > a table. Only I can do that.
> 
> I wasn't referring to that kind of problems but normal INSERT/UPDATE.

That too. If a user does not need to perform a SQL function then that
user has no authorisation to use the SQL verb.

> > In my systems such actions could not happen. No user gets permissions
> > they do not genuinely require. If the programme specification says no
> > 'overdraft' then funds can not be transferred out of an account if that
> > account balance would go negative.
> 
> Assuming everything works as expected, no bugs, no intentional hacks
> and nobody edited the application source without your knowledge ;)

User can not change READ ONLY programme files.

> It's never too late to stop junk from getting stored. Early prevention
> might be better than late prevention, but any prevention is definitely
> better than none! :D

Robust data validation is always an essential requirement for any data
input procedure. There is no point in running a super-doper system if it
can be contaminated with bad data. Acceptance of bad data makes a
mockery of the entire system.

> > That is why I always try to wreck my programmes by entering invalid
> > data.  If I fail to wreck my programmes there is a reasonable certainty
> > others will fail too.
> 
> But it doesn't guarantee that somebody/something else can't.

I think it means no one else can :-)  What I never tell users is every
programme routinely logs every user's details and activities. So if
things go wrong, I read the application's log file.

>  After all, we're only humans and I believe all of us have blind spots
>  which can allow edge cases to escape testing.

No point in me 'escaping testing' of my programmes. I prefer them going
wrong in front of me and not in front of the users. Hence my vigorous
testing policy when I become the user. 

-- 
With best regards,

Paul.
England,
EU.