-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

Some remarques :

• • • Notice: Undefined index: _step in

/var/www/webmail/tmp/trunk/roundcubemail/installer/rcube_install.php on line 39

• • • The step 2's page is fulled of notices, it's unreadable... Same for

step 3 and 4.

Shouldn't you disable the installer, or protect it when a configuration file already exist ? Because for the moment, I just have to go to /installer to get the configuration options of an Roundcube installation... Yes there are a warning, but...

For example, you can turn of it when a config file exist AND when a file like installer.allow doesn't exist. And display a message 'Create a blank "installer.allow" file in the root of Roundcube to reactivate this installer'.

At last, very good work (it's your program too ^^), I think it was one of the most-missing feature of roundcube :)

Regards,

On Thu, 28 Feb 2008 23:07:07 +0100, "Thomas Bruederli" roundcube@gmail.com wrote:

Hi everybody

The install script for RoundCube is almost finished and I'd like you to try out and test it. Just get the latest SVN checkout and point your browser to http://your-roundcube-url/installer/

The installer first checks the PHP environment and folder permissions. The next step shows a form to comfortably set the most common config options. After saving the generated configuration to the according files, the final step of the install script will help you test the config settings. Those who have a Postgres database available are requested to create an empty database and test if the db initialization of the installer works.

Please let me know what you think of it and what's not working correctly. Thanks!

~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/

On Fri, Feb 29, 2008 at 11:31 AM, Michael Baierl mail@mbaierl.com wrote:

Maximilien Cuony [The_Glu] wrote:

...

• • • Notice: Undefined index: _step in

/var/www/webmail/tmp/trunk/roundcubemail/installer/rcube_install.php on line 39

These are just noticies so I think they are fine in there - notices should be disabled anyways - if you code around undefined index notices it will make your life much harder and your code even more unreadable.

I'll disable notices using ini_set()...

...

Shouldn't you disable the installer, or protect it when a configuration file already exist ? Because for the moment, I just have to go to /installer to get the configuration options of an Roundcube installation... Yes there are a warning, but...

Yeah, this should be done. And as you can't expect that you can write to the install dir -) offer the config script for downloading as well -) only allow configuration if a file install.allow exists -) warn the user on the login page that install.allow must be removed if it still exists.

That way noone can access the install script and the admin has to actively enable it and hopefully he also disables it to get rid of the message on the login screen.

I planned to check whether the installer folder exists when showing the login page and display a big fat warning. This should be enough motivation for the admin to remove the installer after use.

Thanks so far! ~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/

On Fri, Feb 29, 2008 at 11:31 AM, Michael Baierl mail@mbaierl.com wrote:

...

Maximilien Cuony [The_Glu] wrote:

...

• • • Notice: Undefined index: _step in

/var/www/webmail/tmp/trunk/roundcubemail/installer/rcube_install.php on line 39

These are just noticies so I think they are fine in there - notices should be disabled anyways - if you code around undefined index notices it will make your life much harder and your code even more unreadable.

I'll disable notices using ini_set()...

i don't think that turning notices of is a good thing, we need to have a good code, not error_reporting(E_ALL ^ E_NOTICE);

List info: http://lists.roundcube.net/dev/

till wrote:

...

i don't think that turning notices of is a good thing, we need to have a good code, not error_reporting(E_ALL ^ E_NOTICE);

I agree. They should be fixed and not hidden!

+1

Robin _______________________________________________ List info: http://lists.roundcube.net/dev/

t.pajor@kei.pl wrote:

i don't think that turning notices of is a good thing, we need to have a good code, not error_reporting(E_ALL ^ E_NOTICE);

Good code has nothing to do with notices; if you code around all notices you just create slower code which is not needed. PHP is so smart about i.e. indexes and just warns you that you might have an error. Notices are great during development for the developer, but not for the end user.

Don't go for 0 noticies, spend your time on 0 warnings and optimized code, but don't waste it on zero notices.

My 2 cents, in the end Till has to decide.

Mike

Michael Baierl http://mbaierl.com/

One OS to fool them all, One browser to find them, One email client to bring them all And through security holes, blind them...

List info: http://lists.roundcube.net/dev/

On Sat, Mar 1, 2008 at 9:45 PM, Thomas Bruederli roundcube@gmail.com wrote:

Notices IMO just destroy the very nice advantages of PHP. They're good for development but don't expect all (of my) code to be notice-free. Especially if you make use of third party libraries (as we do), you cannot guarantee that all code is notice free.

Personally, I have no issues reporting them. :-) Especially all the PEAR stuff should fix those issues and I know no PEAR developer who wouldn't fix this when we report it. Or fixing them since libs like Ilohamail are not actively maintained anymore.

I know we cannot fix all, but we should strive to make at least RoundCube free of notices.

The fact that the PHP interpreter doesn't care about inexisting indexes and undeclared variables is one of the reasons why I like PHP.

I see that, but it's also why PHP has such a bad reputation and people call PHP developers "script kiddies" etc.. I don't mean we have to do a Java like thing, but generally I like my vars type safe, I like to initialize them because then I know what I am dealing with.

I have been through this countless times where a war is not checked and it just goes havoc and brings unpredictable results which are hard to debug and trace.

I agree that there shouldn't be any notices in the installer but many people who install scripts like RoundCube have no idea about PHP and they maybe have notices on. To avoid unnecessary complains and bug reports that aren't really bugs I still vote to disable notices within the installer.

I don't really feel like making this a huge issue for 0.1-stable (after all it's 0.1), but if you have E_NOTICE on while you code and therefor fix your issues, there won't be any issues for people who have them enabled either. ;-)

Till _______________________________________________ List info: http://lists.roundcube.net/dev/

chasd wrote:

I suppose the assumption is that almost everyone will use IMAPS
instead of IMAP. If so, the line specifying requiring sockets on

I don't think this is the case nor a good idea - at least if the IMAP and the Web server are running on the same physical machine it does not make sense to have the overhead of the SSL connection and it does not add any security. So SSL only makes sense if the IMAP and Web host are on separate machines.

My 2 cents,

Mike

On Mar 3, 2008, at 2:23 PM, till wrote:

On Mon, Mar 3, 2008 at 7:12 PM, chasd chasd@silveroaks.com wrote:

...

is displayed, which means the DES key creation is failing. The line in question

...

$value = self::random_key(24);

Isn't "self::" PHP5, and you run PHP4, right?

PHP 4.4.0 on that machine, 4.4.8 on the outside. Please don't ask me why the internal dev machine is using a PHP that
old ;)

I wasn't familiar with that syntax, the only other time I saw it was
referencing PEAR, so I ( wrongly ) assumed it was PEAR related, not
PHP5 related.

The requirements says PHP 4.3.1 or newer, I can test on 4.3.1 if no
one else is. Sounds like 4.4.0 is the oldest that has been tried.

Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265

List info: http://lists.roundcube.net/dev/

Thomas Bruederli wrote:

Please let me know what you think of it and what's not working correctly. Thanks!

Hi Thomas,

the install script of stable complains about missing sockets: Sockets: NOT OK but everything works perfectly fine - can you please tell me why sockets are required?

Thanks,

Michael

Michael Baierl http://mbaierl.com/

MBA? Married But Available! _______________________________________________ List info: http://lists.roundcube.net/dev/

On Mar 4, 2008, at 6:54 AM, Michael Baierl wrote:

Thomas Bruederli wrote:

...

Please let me know what you think of it and what's not working correctly. Thanks!

Hi Thomas,

the install script of stable complains about missing sockets: Sockets: NOT OK but everything works perfectly fine - can you please tell me why
sockets are required?

I believe it is for IMAP over an encrypted connection ( IMAPS ) so if
you don't use IMAPS, technically it isn't required. Since a large
majority of end users will need IMAPS support, it is better to
require Sockets support than to continually answer the question "Why
won't IMAPS work ?"

A "manual" install ( documented at http://trac.roundcube.net/wiki/ Howto_Install ) would allow those that don't have sockets support and
don't want to use IMAPS to use RoundCube.

I use Fedora, and the PHP package for that distro includes Sockets
support. I am not sure if the PHP package for other distros is
configured similarly. I think Sockets support is not on by default if
you compile PHP yourself, however if someone is capable of compiling
PHP, they can easily add --enable-sockets when they invoke
"configure." If someone is compiling PHP and _doesn't_ know how to do
that, it might be best for the entire universe if I traveled to their
locale and slapped them. Well, maybe not, that's a lot of bad karma
for me ;)

I think it was a good decision to require Sockets support, and modify
the documentation accordingly.

Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265

List info: http://lists.roundcube.net/dev/

chasd wrote:

I believe it is for IMAP over an encrypted connection ( IMAPS ) so if
you don't use IMAPS, technically it isn't required. Since a large
majority of end users will need IMAPS support, it is better to
require Sockets support than to continually answer the question "Why
won't IMAPS work ?"

Hi Charles, I have to disagree here - as I already outlined before IMAPS is a bad idea if the IMAP host is running on the same machine as it does not increase security and just slows the system down. So I would recommend using a warning instead of an error and explaining why Sockets might be needed. The same applies to the config file - if IMAPS is required the comment should indicate that sockets are needed and the installer can complain about that fact in the next step when actually SSL is entered.

I use Fedora, and the PHP package for that distro includes Sockets
support. I am not sure if the PHP package for other distros is
configured similarly. I think Sockets support is not on by default if
you compile PHP yourself, however if someone is capable of compiling
PHP, they can easily add --enable-sockets when they invoke
"configure." If someone is compiling PHP and _doesn't_ know how to do
that, it might be best for the entire universe if I traveled to their
locale and slapped them. Well, maybe not, that's a lot of bad karma
for me ;)

Some users might have the knowledge to compile PHP by themselves but they are in a restricted environment and can't install it on their server...

Best regards,

Michael

On Tue, Mar 4, 2008 at 3:38 PM, chasd chasd@silveroaks.com wrote:

...

This is fixed in 0.1-stable (WOO, this reads great!). :D

Yes, there is a fresh smell in the air, and the birds are singing Beatles tunes. I missed that change yesterday because I modified my script that syncs my SVN checkout to the live directory on the dev server, which actually turned off syncing via a typo. I don't test the SVN checkout directly.

Was stable a branch off of trunk, or is it simply trunk at a specific revision number ?

Up to the release, we worked in trunk.

If so, what is the SVN revision number of the stable release ? I'm at 1179 but this morning SVN is at 1181.

You can check out what we released as "0.1-stable" from SVN here: https://svn.roundcube.net/branches/release-0.1-stable

Till _______________________________________________ List info: http://lists.roundcube.net/dev/

I have to disagree here - as I already outlined before IMAPS is a bad idea if the IMAP host is running on the same machine as it does not increase security and just slows the system down.

I don't use IMAPS either for my installs because it isn't necessary
in my environment.

So I would recommend using a warning instead of an error and explaining why Sockets
might be needed.

For my environment, I would have liked to have seen something like
what you suggest. Actually I think the first page of the installer should have a few
questions about how you want RC set up, and then the tests can
reflect your environment and desired configuration. For example if
Sockets support isn't needed, the tests for it would be skipped.

However, even though RC is now at 0.1 stable, the installer is really
at 0.001 beta in comparison. The installer didn't hit the code base
until very recently. I think requiring Sockets support is a decent
trade-off to get the stable release out the door with a functioning
installer that hits the sweet spot for most installs. At its current
revision level the installer could be better, as you are pointing
out. Just having an installer is a huge step for RC and most of its
users, even if their are niggles with how it is implemented. It would
have been nice to have an installer that takes some different options
into account, but I think adding those options to the installer would
have delayed the stable release.

Some users might have the knowledge to compile PHP by themselves but they are in a restricted environment and can't install it on their
server...

Yes, if they are in a restricted environment, it doesn't matter what
their skill level is.

My point was that for those where the installer doesn't work the
traditional manual install is available.

Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265

List info: http://lists.roundcube.net/dev/

On Tue, Mar 4, 2008 at 11:04 PM, Jim Pingle lists@pingle.org wrote:

Thomas Bruederli wrote:

...

Please let me know what you think of it and what's not working correctly. Thanks!

This may be partly my ignorance of svn commands showing, but is there any way to prevent the 'installer' folder from coming back every time you run "svn update"?

I tried setting svn:ignore to "installer" on the RC directory and I also tried setting svn:ignore to "*" on the installer folder, but either way it still pulls in all the files when I try to update.

I'll keep tinkering, I just want to make sure that I don't forget (again) to remove the installer folder every time.

svn:ignore is a global setting. Not meant for your personal install, please don't commit it. ;-)

I'd probably wrap the "problem" into a small bash script and rm -rf installer/ when you fetched it. No idea otherwise.

Till _______________________________________________ List info: http://lists.roundcube.net/dev/

[I sent this earlier but forgot to copy the list] till wrote:

...

I tried setting svn:ignore to "installer" on the RC directory and I also tried setting svn:ignore to "*" on the installer folder, but either way it still pulls in all the files when I try to update.

svn:ignore is a global setting. Not meant for your personal install, please don't commit it. ;-)

No worries, I don't have commit access. :) Even so I thought it still worked on read-only local working copies. Guess I need to read the SVN book again.

I'd probably wrap the "problem" into a small bash script and rm -rf installer/ when you fetched it. No idea otherwise.

That's one way to go, but doesn't seem like a very elegant solution. I'm sure this "problem" will pop up on the list and in the forums from time to time. It might warrant an FAQ entry once a good solution is worked out. I'll try to tinker with this at work and see what I can come up with.

Worst case, I just need to remember to (a) rm -rf the installer directory, and (b) test the install after an update. If I at least did (b), I hope I would notice the big giant red warning!

Jim

List info: http://lists.roundcube.net/dev/

chasd wrote:

...

...

This may be partly my ignorance of svn commands showing, but is
there any way to prevent the 'installer' folder from coming back every time
you run "svn update"?

...

I'd probably wrap the "problem" into a small bash script and rm -rf installer/ when you fetched it. No idea otherwise.

You can chain the commands using a semi-colon -

svn update ; rm -rf installer

I may have to do something like that. I already have several other aliases for similar situations, such as updating ports on FreeBSD (csup ports-supfile; cd /usr/ports; make fetchindex).

But then you end up downloading the installer files each time you
update. A better command would be

mv ./installer1 ./installer ; svn update ; mv ./installer ./installer1

which moves the installer files out of the way during use, but moves
them back so svn only downloads / applies changes.

The problem with this approach is that it leaves those files accessible via the web, which is the reason for the warning in the first place. Sure, the path is different but it's just security by obscurity, which is never a good thing on its own. The other suggestion of "chmod 000 installer" is better, but still not as good as never downloading the folder in the first place when updating a current installation.

I suppose the folder could be moved to/from a folder that is not web-accessible, but that would only further complicate the situation.

Here is another interesting possibility: Could the installer chmod itself 000 after it is finished running?

Jim _______________________________________________ List info: http://lists.roundcube.net/dev/

chasd wrote:

...

I suppose the folder could be moved to/from a folder that is not
web-accessible

I think that is the best approach if you are concerned about security.

I would still prefer it didn't exist at all on an existing install, as it shouldn't be necessary. :)

You could have an apache directive forbidding access to "installer1"

Or even for 'installer' for that matter, and the warning message could check for such a condition.

...

but that would only further complicate the situation.

If you have an automated way to do it, the complexity is hidden and
forgotten.

I'd prefer a simple/elegant solution over hidden complexity. In my experience, that would inevitably lead to breakage down the road and more confusion over how to fix it (unless it's well-documented).

...

Here is another interesting possibility: Could the installer chmod
itself 000 after it is finished running?

The possibility I thought of was to tar the directory up before
removing it. When it comes time to update, untar the file.

If the files are tarred up, they can't be executed, only downloaded.

That's another good possibility. Given any of these choices, though, I would go for the simpler choice of aliasing "svn up; rm -rf installer/".

Here's another choice: Have a config option, that if absent (either left out or if there is no config file) activates the installer. It could be something like $rcmail_config['post_install'] = true. If the variable is set, the installer scripts would die or become inactive.

Some other projects use such a variable to prove that you have edited the default config.

Jim _______________________________________________ List info: http://lists.roundcube.net/dev/

Eric Stadtherr wrote:

Jim Pingle wrote:

...

I would still prefer it didn't exist at all on an existing install, as it shouldn't be necessary. :)

The fact that you're worried about an SVN update bringing back the installer directory implies that you're running your live web site from your Subversion working copy. I wouldn't recommend this, since it opens up access to all of our .svn directories on your web server. You could get creative with access rules and/or .htaccess files, but that's probably introducing more complexity than copying the real files from your working copy to your web root. The rsync script posted earlier is similar to the installer script that I use (which excludes the .svn directories and other files that I don't want the web server serving up).

The access part is easily solved with a rule in Apache's main config like so:

<DirectoryMatch "^/.*/.svn/"> Order deny,allow Deny from all

</DirectoryMatch>

Not too exotic or creative, and if done site-wide, ensures that nobody's .svn directories get exposed, even by accident.

RoundCube is still considered in "testing" for us, so end-users are still warned that there could be outages or breakage while we test settings or attempt bug fixes for other users. Once it moves into real "production use" we might use some other setup like you describe, where files get copied to the main "live" site and away from the testing setup.

The main reason I bring it up though is not just for me and my install, but because I have a feeling we'll be seeing the question a lot. It would be nice to have an official answer worked out, or at least some solid suggestions, to put in the FAQ.

Jim _______________________________________________ List info: http://lists.roundcube.net/dev/

till wrote:

On Thu, Mar 6, 2008 at 2:05 PM, Jim Pingle lists@pingle.org wrote:

...

(...) The access part is easily solved with a rule in Apache's main config like so:

<DirectoryMatch "^/.*/.svn/"> Order deny,allow Deny from all

</DirectoryMatch>

If you really want to stick with svn do an svn export, not an checkout/update.

Export rids you of the .svn directories etc..

I've hit a couple issues when exporting from a working copy. First, it doesn't copy local-only files such as main.inc.php and db.inc.php. It also doesn't copy ownership/permissions from the working copy that aren't set in svn properties. You also lose the ability to quickly update with "svn update" rather than removing the whole tree and exporting again, or forcing an export and possibly having some inconsistent files.

As part of a deployment procedure, it has its place, but it's still a lot more complex than using a working copy and blocking public access to the .svn directories. It's a lot more convenient that way, even if it does lend itself to foot-shooting from time to time.

Jim

List info: http://lists.roundcube.net/dev/

On Tue, 04 Mar 2008 17:04:53 -0500, Jim Pingle lists@pingle.org wrote:

Thomas Bruederli wrote:

...

Please let me know what you think of it and what's not working correctly. Thanks!

This may be partly my ignorance of svn commands showing, but is there any way to prevent the 'installer' folder from coming back every time you run "svn update"?

You could change ownership to root, group to www-data (apache), then chmod 700. svn update works and the folder is not visible nor accessible for the web server. IMO this is protection enough. After all, you trust the web server to protect your config file too.

For the rest of the discussion, roundcube could also add a login for the installer. Another great project, "gallery" (gallery.menalto.com), does this for their updater script (run after svn updates) and it works pretty well (of course, you can still just delete/move the folder..).

Sebastian

List info: http://lists.roundcube.net/dev/

[see below] Matt J. Sorenson wrote:

Jim Pingle wrote:

...

till wrote:

...

On Thu, Mar 6, 2008 at 2:05 PM, Jim Pingle lists@pingle.org wrote:

...

(...) The access part is easily solved with a rule in Apache's main config like so:

<DirectoryMatch "^/.*/.svn/"> Order deny,allow Deny from all

</DirectoryMatch>

If you really want to stick with svn do an svn export, not an checkout/update.

Export rids you of the .svn directories etc..

I've hit a couple issues when exporting from a working copy. First, it doesn't copy local-only files such as main.inc.php and db.inc.php. It also doesn't copy ownership/permissions from the working copy that aren't set in svn properties. You also lose the ability to quickly update with "svn update" rather than removing the whole tree and exporting again, or forcing an export and possibly having some inconsistent files.

As part of a deployment procedure, it has its place, but it's still a lot more complex than using a working copy and blocking public access to the .svn directories. It's a lot more convenient that way, even if it does lend itself to foot-shooting from time to time.

Hi (quick intro: I'm a recent discoverer of roundcube, and have been lurking on this list for about a week or so... kudos to you all!)...

I get what Jim desires concerning the installer... but I also tend to agree with Eric Stadtherr, Till, et.al. that a deploy/update process based solely on svn up'ing a working copy from roundcube svn isn't sufficient or a good idea. Sure it's easy, sure you can hide the .svn dirs, but it can be pretty fragile, and it'll always leave more to be desired...

What about creating your own svn repository, adding roundcube to it as an svn:externals project, then branching that within... that would get you complete control over your own roundcube repo... allow you to set svn:ignore on whatever files you don't want deployed, etc... AND allow you to keep your own config files under revision control... AND still enable you to merge in changes from roundcube svn. And still have your choice of deployment method: svn working copy, svn export, rsync...

at least, I think that would work, thoughts?

Welcome to the discussion! A quick note: to make a thread easier to follow, please avoid Top Posting (http://en.wikipedia.org/wiki/Top_posting) unless the rest of the thread has already been going that way.

You are right, there are some downsides to running the working copy directly on the web, but at least for me in my setups the benefits outweigh any problems I have yet to encounter. I'd be interested in the results of a survey of people who use the SVN version, what percentage run the working copy "live" in this way.

A local SVN repo sounds interesting, but still adds too much complexity for my taste. I like to keep things as simple as possible, so that anyone who comes along after me doesn't have to spend an undue amount of time digging through documentation or guesswork at how the system was set up.

Jim _______________________________________________ List info: http://lists.roundcube.net/dev/

Philip Iezzi wrote:

There should be a configuration directive as e.g. $rcmail_config['installer_disable_warning'] = false;

Done. I'd suggest that this parameter should remain undocumented (for devs only).

~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/

till wrote:

On Fri, Mar 14, 2008 at 10:53 PM, Thomas Bruederli roundcube@gmail.com wrote:

...

Philip Iezzi wrote:

...

There should be a configuration directive as e.g. $rcmail_config['installer_disable_warning'] = false;

Done. I'd suggest that this parameter should remain undocumented (for devs only).

It's a huge convenience thing for some, but I agree. Creates more issues if we advertise it.

I mentioned this before, but it may have been lost in the noise of that thread:

Why not check for such a flag in the installer itself, and render it inert if it's found? If the installer is disabled, it would be safe to leave it laying around.

Plus it could be a documented and supported flag, instead of hidden.

Jim /I'll shut up now :)

List info: http://lists.roundcube.net/dev/