SiT! Bugs

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000832SiT!setup/configpublic2009-07-30 13:472012-01-17 11:00
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000832: Setup should check whole environment
DescriptionSetup should check that the whole stack that SiT runs on is suitable and fit for purpose. This means checking everything from php and mysql versions to what php extensions are installed, what SQL mode is in use, what php configuration (esp. email configuration is in use) and db collation.

Setup should show PASS, FAIL, or WARN for each check, some checks will mean that setup can't continue, others will just produce a warning that might mean some feature's wont work. e.g. if the php IMAP extensions is missing incoming email won't work.
TagsNo tags attached.
Attached Files

- Relationships
duplicate of 0000986closed Visual checking of settings/config 

-  Notes
User avatar (0001474)
kieran (administrator)
2009-07-30 14:38
edited on: 2009-07-30 14:38

This might be an unpopular idea but it kinda lends in to what you've written here.

Atm there are too many paths through the setup, I'd like to see it more linear with every step given a pass or fail like you said. I'm not suggesting we remove some of the cleverness e.g. when the DB goes away or setup isn't completed but the setup should be more rigid and linear. To prevent it being too long with every step, we can check more than one step per page. For instance now we have a page just for attachment directory, that could be included in a 'config' page which checks numerous things.

User avatar (0001475)
ivan (administrator)
2009-07-30 20:10

I agree 100%, at the moment the checking and the steps are mixed leading to the rather strange paths people can take through setup. It's clear that method of doing things leads to bugs and unexpected end-results. I'm definately all for making it a more linear process. I'd like to see a breadcrumbs like, progress through the setup possibly even with the ability to go back a step (maybe?).

The main thing about the current setup I don't want to lose is the ability to run it against a half installed SiT and it will diagnose what needs to be done and carry on where it left off.
User avatar (0001476)
kieran (administrator)
2009-07-30 20:31

If all the checks are consolidated, what's the problem with showing all the checks as being passed from the very beginning when resuming setup? I don't think the partial setup is that big a use-case, I don't know many other software that jumps you straight back in halfway through, most users might consider this confusing. I do think we should do something with certain special cases like the DB being installed though.
User avatar (0001477)
paulh (administrator)
2009-07-30 20:44

I agree, the one of the first things we should do (if not the first) is check the pre-reqs (PHP, MySQL).

We should also check as services are enabled (IMAP, LDAP etc) that the necessary components are available (this probably wants to be a bit more dynamic), we can do the same with checking attachments is writable

Perhaps have at the end a summary of Passed, warning and failed?

Its worth having a look at the setup for GOSA its pretty good
User avatar (0001478)
ivan (administrator)
2009-07-30 22:56

Yeah the gosa setup has heavily influenced the way I was thinking. I don't see any difference in the way I was thinking and the way both of you are thinking. I just think that some of the checks should be

do we have a config file?
do we have a db connection?
do we have a database?
do we have a schema in that database?
is that schema up to date?

and whatever the situation, we handle it. Don't think it's a big departure from the way most setup programs work. We have one script that handles installs and upgrades remember, a lot of apps have two.
User avatar (0002178)
paulh (administrator)
2009-12-03 19:21

Copying status from 986
User avatar (0002199)
paulh (administrator)
2009-12-03 20:48

Ivan why was 986 targetting against 3.50p1? its not a bug fix
User avatar (0002214)
ivan (administrator)
2009-12-04 11:02

I don't know why it was targeted against 3.50p1 that was rather unrealistic, I guess it was a mistake.
User avatar (0002501)
ivan (administrator)
2010-02-26 09:25

Setup should check for mbstring and other extensions needed. [^]
User avatar (0002502)
ivan (administrator)
2010-02-26 09:50

We should also note that the CLI version of PHP used for incoming email may not have the required extensions, not sure how we can check for this, but some docs explaining might be helpful.
User avatar (0004412)
nicdev (developer)
2012-01-17 11:00

As discussed on IRC, a limitation exists in some versions of PHP (5.2- 5.3.7 RC1) where the PCRE limitation (backtrack limit) for preg_replace is set to 100 000 per Default. If this is true, SiT can fail when the function replace_specials() is called on a large string of bodytext. This stops the script (No error in the log), and produces a SiT email window with a blank screen.

The idea is to check this during Setup to see if the limit is set too low, and warn about it. The php.ini setting is "pcre.backtrack_limit".

- Issue History
Date Modified Username Field Change
2009-07-30 13:47 ivan New Issue
2009-07-30 14:38 kieran Note Added: 0001474
2009-07-30 14:38 kieran Note Edited: 0001474
2009-07-30 20:10 ivan Note Added: 0001475
2009-07-30 20:31 kieran Note Added: 0001476
2009-07-30 20:44 paulh Note Added: 0001477
2009-07-30 22:56 ivan Note Added: 0001478
2009-12-03 19:20 paulh Relationship added duplicate of 0000986
2009-12-03 19:21 paulh Note Added: 0002178
2009-12-03 19:21 paulh Status new => confirmed
2009-12-03 19:21 paulh Target Version => 3.50p1
2009-12-03 20:48 paulh Note Added: 0002199
2009-12-04 11:02 ivan Note Added: 0002214
2009-12-04 11:28 ivan Target Version 3.50p1 =>
2010-02-26 09:25 ivan Note Added: 0002501
2010-02-26 09:50 ivan Note Added: 0002502
2012-01-17 11:00 nicdev Note Added: 0004412

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker