| 18:18:30 | k-fish | fine. 2. SQL portability |
| 18:18:40 | k-fish | who did not read my email on this? |
| 18:19:03 | hondzik | i did |
| 18:19:30 | k-fish | ok. so you all know (roughly) what the status is. |
| 18:19:43 | k-fish | i did not committ yet, because of some issues to be discussed later. |
| 18:20:08 | k-fish | but there needs work to be done, after i committ those changes. just to warn you :) |
| 18:20:35 | k-fish | ok, who could test on what database, aside MySQL and PostgreSQL? |
| 18:20:58 | hondzik | not me, I have only MySQL installed :( |
| 18:21:24 | tom | I can test mssql |
| 18:21:33 | k-fish | that would be good. |
| 18:21:35 | canani | I can test PostgreSQL |
| 18:21:56 | k-fish | oracle anybody? msql? db2? ...? |
| 18:22:08 | canani | and maybe firebird ... |
| 18:22:27 | k-fish | sapdb? |
| 18:22:48 | k-fish | does anyone know someone else who could test on other db's? |
| 18:23:05 | k-fish | if not, we'll have to call for volunteers :) |
| 18:23:19 | brr | Sybase. Did you mention that? |
| 18:23:40 | k-fish | no. do you have that available? |
| 18:24:17 | brr | Sorry. At work we use both Oracle, Sybase and MS SQL. But it is running servers... I don't take the change to run tests on them. |
| 18:25:23 | k-fish | production systems running mgw? |
| 18:25:32 | canani | i have many |
| 18:25:42 | k-fish | brr: could you create a parallel test-only install? |
| 18:25:49 | k-fish | canani: so you are out friend :) |
| 18:25:51 | canani | of course |
| 18:25:55 | k-fish | s/out/our/ |
| 18:26:10 | k-fish | ok, so it seems testing is not that big a problem. |
| 18:26:34 | k-fish | i'll try to create an overview page, were we can summarize test results. |
| 18:26:44 | brr | k-fish: Sorry. I think it will be difficult. I don't have the knowledge or the installation CDs to do that.... |
| 18:27:02 | k-fish | brr: ok, no problem. you'd find too many bugs anyway ;) |
| 18:27:16 | k-fish | anything else on that subject that wasn't mentioned yet? |
| 18:27:52 | k-fish | ok, my plan is this: |
| 18:28:16 | k-fish | as soon as moregroupware *runs* on PostgreSQL (and possibly other systems), go ahead and ... |
| 18:28:35 | k-fish | add foreign key constraints! tada! opinions? |
| 18:28:49 | canani | yes, please! |
| 18:29:39 | k|p | transactions? .. does that work with adodb even if the db doesn't support it? |
| 18:29:54 | --> yoyo- (~YoYo@N869P031.adsl.highway.telekom.at) has joined #moregroupware |
| 18:30:07 | k-fish | hm, transactions... i'd have to look at the docs. |
| 18:30:21 | k-fish | is this something that is of great importance? |
| 18:30:36 | k-fish | (in moregroupware in particular, i mean) |
| 18:31:47 | k-fish | from adodb manual: |
| 18:31:54 | k|p | well, for a clean db yes, but because many db's don't support it, we probably have to compensate for failures in code ourselves |
| 18:32:02 | k-fish | BeginTrans() Returns true if successful. Some databases will always return false if transaction support is not available. |
| 18:32:15 | k|p | (read many=mysql) |
| 18:32:23 | hondzik | I don't think we need transactions, but it should be nice feature |
| 18:32:52 | k-fish | so it should work regardless of the db. we could add this were it fits, and those who use a database lacking transaction support - their fault. no? |
| 18:33:00 | k-fish | hondzik: yep. |
| 18:33:05 | canani | foreign key constraints are more important in my opinion. |
| 18:33:06 | hondzik | k|p: i think mysql = most of mgw users |
| 18:33:16 | k|p | hondzik : i know :( |
| 18:33:29 | k-fish | hondzik: well, it's the only thing that works right now... :( |
| 18:33:46 | k-fish | i'd migrate to pgsql asap. |
| 18:33:49 | k|p | talk about transactions again when mysql 4 is out |
| 18:34:13 | k-fish | well, even late 3.23.x releases support transactions, if using innodb, no? |
| 18:34:33 | k-fish | maybe we should add something to setup, that makes it possible to choose table type for mysql. |
| 18:35:30 | hondzik | or maybe detect mysql version (if its possible) and choose best type... |
| 18:35:48 | k|p | i would wait for mysql to get things right .... a lot of work for just a minor issue |
| 18:36:45 | k-fish | true. we probably have more important things to do. |
| 18:37:09 | k-fish | so we could add this, and those who want it to work, should use the "right" database. |
| 18:37:17 | k-fish | what else on databases stuff? |
| 18:37:37 | hondzik | some upgrade mechanism? |
| 18:37:46 | brr | Upgrade possabilities? Or will you discuss that later? |
| 18:38:06 | hondzik | probably later... |
| 18:38:40 | k-fish | hm. fits here - let's finish SQL portability, and talk about upgrades. |
| 18:38:50 | k-fish | k|p: do you have some roadmap for this? |
| 18:39:51 | k|p | wel, it's almost impossible to upgrade change like the one from configtagid to configtag name automaticly, but minor changes, added columns etc are doable |
| 18:40:23 | k|p | as long as we define the datatypes that can be used in db |
| 18:40:36 | k-fish | true. such big changes need a seperate update script, or sth like that. |
| 18:40:58 | k-fish | well, the datatypes i used for now do most things we need, and are portable. |
| 18:41:14 | k-fish | if those suffice, we don't a meta type system. |
| 18:41:16 | k|p | yes, they can be avoided if the db design is thought through well when making a design |
| 18:41:32 | k-fish | there are two principal ways i see for db upgrades. |
| 18:41:49 | k|p | yes, if we limit to those db upgrade can be done |
| 18:41:54 | k-fish | 1. prepare update sql files manually (alter table ...) |
| 18:42:14 | k-fish | 2. create a "diff" on the fly, by comparing the existing db, and the install.sql file. |
| 18:42:23 | k-fish | i'd vote for 1... (to be honest) |
| 18:42:33 | brr | Oh no! |
| 18:42:42 | hondzik | me too |
| 18:42:44 | k|p | both options cry for transactions btw :p |
| 18:42:59 | k-fish | brr: prepare manuyll, apply automatically. like this... |
| 18:43:26 | <-- yoyo- has quit ("bye") |
| 18:43:28 | k-fish | in setup/ of each module, we have install.sql, like now. and probably uninstall.sql (more from k|p, probably) |
| 18:43:50 | k-fish | and then thngs like update-05.sql, update-06.sql |
| 18:44:05 | k-fish | those have to be prepared for each release, and will then be applied by setup, if needed. |
| 18:44:18 | k|p | uninstall.sql -> i vote YES (strongly) |
| 18:44:30 | k-fish | that's what i'd try, though i am open for better suggestions all the time! |
| 18:44:59 | brr | Remember that not everyone like to hack databases! |
| 18:45:04 | k|p | i vote for option 1 too, option 2 is tricky and will introduce quite a few problems (i know) |
| 18:45:15 | k-fish | brr: setup will do it for you! |
| 18:45:23 | k|p | brr, option 1 will be just as easier as option 2 in the end |
| 18:45:55 | k-fish | othr way would be to use metabase for this. but it needs XML db descriptions... |
| 18:46:04 | brr | OK! If I can e. g. upgrade my MGW 0.6.3 installations to e. g. MGW 0.6.7 without too much manually database hacking I will be very satisfied! |
| 18:46:10 | k-fish | it could do 2. out of the box (should do) |
| 18:46:46 | k-fish | brr: i imagine setup to look at the version, then apply the needed upgradexx.sql files |
| 18:47:16 | k-fish | though it might be tricky to rely on the moregroupware version alone. module version numbers would probably be better. hm.. |
| 18:47:31 | brr | k-fish: OK. No more comments from me regarding this topic! |
| 18:48:23 | k|p | k-fish : a quick look at metabase, looks good, who's gonna do it? |
| 18:49:35 | k-fish | do what? take the (closer) look? |
| 18:49:56 | k|p | yes :) |
| 18:50:35 | k-fish | hm. i could do it. but we'd have to coordinate this with the new setup code of yours. |
| 18:51:10 | k-fish | any more thoughts on this? |
| 18:51:12 | k|p | will we limit db support to those db's supported by adodb and metabase? |
| 18:51:19 | k-fish | k|p: yes. |
| 18:51:53 | k|p | i would be happy to hand over my setup hacks to anybody that want's to use it further :) |
| 18:53:21 | canani | regarding testing ... is there a list of which modules are assigned to which developer ? |
| 18:53:41 | canani | so that i can send testing reports to the correct person ? |
| 18:54:22 | canani | or should I pot it to the delveloper's maillist? |
| 18:54:23 | brr | http://www.moregroupware.org/tasks.php |
| 18:54:25 | k-fish | canani: yes, see www.moregroupware.org/tasks.php |
| 18:55:07 | hondzik | it's out of date :( but I can update it... |
| 18:55:14 | k-fish | k|p: you want to hand over the setup stuff to someone else? what's still missing? |
| 18:55:22 | k-fish | hondzik: not too much out of date... :) |
| 18:55:40 | k-fish | hondzik: i have access to it now as well. |
| 18:56:06 | k-fish | canani: but best is to submit bug reports via sf.net |
| 18:56:21 | hondzik | yeah i know, thanks for updating it, i absolutely forgot to do it :( |
| 18:56:22 | k|p | k-fish : nothing compared to current setup i think (asside from a little code cleaning/nicening) |
| 18:57:23 | --- Notify: newb is online (brunner.openprojects.net). |
| 18:57:24 | k-fish | k|p: ok, so why not add it to cvs? needs to be done along with the new xml files and mod manager, no? |
| 18:57:30 | k|p | k-fish : i can clean it all up and consider it stable next week |
| 18:58:04 | k|p | k-fish : yes, ok |
| 19:00:03 | k-fish | ok. after that we'll look at upgrade possibilities. anything else on this? |
| 19:00:50 | hondzik | not from me :) |
magic_quotes_gpc
| 19:02:05 | k-fish | ok. 3. magic_quotes_gpc() |
| 19:02:15 | k-fish | i'd like to drop that requirement. |
| 19:02:33 | k-fish | to do this we need to ensure proper quoting of all data before db insertion. |
| 19:02:48 | k-fish | was in my mail as well. anything we need to dicuss on this? |
| 19:03:19 | hondzik | only needed is to use $conn->quote($HTTP_...) ? It should be done quikly I think |
| 19:04:59 | k|p | all is clear here |
| 19:05:07 | k-fish | hondzik: basically, yes. or cast to integer for numbers. |
| 19:05:29 | hondzik | ok, clear |
| 19:05:30 | k-fish | and if working on a file, we could replace the qstr() call with the quote() call |
| 19:06:11 | k-fish | ok, who is going to test this? we need to make sure to hit all the places we need :) |
| 19:06:19 | k-fish | notes, todo and contacts work |
| 19:06:33 | k-fish | projects will be taken care of. |
| 19:06:35 | k-fish | (by me) |
| 19:06:57 | k-fish | webmail2 - tom is this clean now? i think you did that, right? |
| 19:07:00 | hondzik | i'm not sure about calendar, but Išll look at it |
| 19:07:00 | tom | webmail, of course |
| 19:07:38 | tom | only those that were buggy, there are many addslashes in the code |
| 19:09:19 | tom | I'll change the others |
| 19:09:25 | k-fish | addslashes()? make sure you only do this if magic_quotes is off... |
| 19:09:45 | k-fish | ok, volunteers for checking the other modules? |
| 19:10:01 | k|p | <- admin, settings |
| 19:11:24 | k-fish | come on people :) |
| 19:11:54 | k|p | is brr gone? |
| 19:12:08 | k-fish | ok, i'll check partprog and outboard |
| 19:12:26 | k-fish | and brr has to do the remaining modules :) |
| 19:12:34 | k-fish | we'll see. |
| 19:12:42 | hondzik | and i'look at settings |
| 19:12:59 | k-fish | i will remove the check for magic_quotes_gpc=onn from setup then, ok? |
| 19:13:17 | tom | ok |
| 19:13:17 | hondzik | ok |
| 19:13:26 | k-fish | fine. |
| 19:13:42 | k|p | hondzik : i wanted to do that, there is no sql in there anyway :p |
| 19:13:55 | hondzik | yeah, i know:) |
| 19:14:10 | k-fish | very funny :) |
logging functionality
| 19:14:22 | k-fish | next: 4. logging code. k|p, your turn... |
| 19:14:24 | hondzik | so you can do settings and i'll take admin |
| 19:14:32 | k|p | hondzik : k |
| 19:15:16 | k|p | I wrote a simple class that allows you to log action/whatever like: |
| 19:15:29 | k|p | $L->_log(ERROR, "Error opening module dir", __LINE__, __FILE__); |
| 19:16:42 | k|p | there are different logging levels ... this may help in solving a few bugs if ppl add logs of thier sessions |
| 19:16:54 | k-fish | can this be used statically? L::_log()? |
| 19:17:05 | k-fish | probably... where is this configured? |
| 19:17:11 | k|p | are number of things are logged like session, user, module, etc |
| 19:17:27 | k|p | what do you mean staticlly? |
| 19:18:06 | k-fish | well, do we have to do a global $L before we can use it? or can we just call it without creating an instance? |
| 19:18:19 | k-fish | never used that feature, but it seems cool :) |
| 19:18:46 | k|p | ow .. in functions ... erm .... dunno |
| 19:19:58 | k-fish | well, anyway. would this be in userfunc? |
| 19:20:26 | k|p | probably not ... but you shouln't log to much i think, more like check points in your code ... a lot of things fail without reason (a saw login problems on the list for example) |
| 19:20:51 | IpSo__ | Does MGW have a "action log" ? ie: a log explaining all actions carried out in a certain module? |
| 19:21:56 | k|p | IpSo__ : no, that's why i propose this. the admin module can be modified to view logs |
| 19:21:58 | k-fish | k|p: if i add a logging call, is it done everytime, or only if some debug flag is set? |
| 19:22:20 | k-fish | :) |
| 19:23:14 | k|p | k-fish : when creating the class you can define the logging level: $L = new logger(ERROR|WARNING|NOTICE|INFO); |
| 19:23:37 | k|p | the levels should be configurable somewhere |
| 19:24:23 | k-fish | ok. so we'd have to create an instance early in the code, and configure log level there. |
| 19:24:45 | k-fish | what do the others think about that? would you think this is useful for development? |
| 19:24:46 | IpSo__ | k|p: But you stated you shouldn't log too much? What I'm getting at is a log that has entries such as: Joe Blow Logged In -> Joe Blow deleted appointment -> Joe Blow deleted contact -> Joe Blow Logged Out. |
| 19:25:01 | k|p | yes, include the class in container and initiate it in appconfig somewhere |
| 19:25:26 | k-fish | IpSo__: ah. that is something different. hm. do we need that? like a transaction log. |
| 19:25:44 | tom | I think this can help finding bugs |
| 19:25:48 | IpSo__ | k|p: Something like that, yes, it can get quite large (easily purged though) can be _very_ useful for tracing steps back. If your wondering where an appointment went, or who changed settings in a project and when etc... |
| 19:26:42 | k-fish | maybe this can be done with the same function. |
| 19:26:59 | k-fish | add it on important "checkpoints", as suggested. |
| 19:27:09 | brr | Maybe the logging can show if someone has tried to hack into MGW? |
| 19:27:23 | k-fish | and in normal use just log the most importnat stuff, and when developing, set debug level higher, and get *huge* amounts of data. |
| 19:27:30 | brr | Maybe the user should have been closed after e. g. 3 or 5 wrong tries to log in. |
| 19:27:32 | k|p | IpSo__ : yes, that would be nice .. log Joe Blow deleted as INFO ... logs are rotated after a certain size ... filepointer is kept open during the script so the only log time spent is writing so to disk ... a good kernel handles this ok :) |
| 19:28:01 | IpSo__ | k-fish: I've implemented something similar on a current project I'm working on, and it has been invaluable. I log all kinds of things. Everything from failed login attempts, to editing/deleting/inserting any item in the application. |
| 19:28:41 | k-fish | ok, would you two (IpSo__ and k|p) like to tune the concept a bit more, and propose a method for logging? |
| 19:29:01 | k|p | IpSo__ : as long as you define enough log level, you can log anything (btw, my tab button dislikes you again :p) |
| 19:29:06 | k|p | k-fish : gladly |
| 19:29:17 | IpSo__ | ;) |
| 19:29:19 | k|p | :p |
| 19:29:46 | k-fish | ok. so we'll look forward to your proposal then :) |
| 19:30:00 | k-fish | anything else on this topic? |
| 19:30:13 | k-fish | maybe from a real user: brr, what would you like to log in daily use? |
| 19:30:17 | IpSo__ | ability to set log levels per module? |
| 19:31:00 | k|p | IpSo__ : we will make great things i think :) |
| 19:31:09 | tom | globals should be better to read the logs ? |
| 19:31:27 | canani | contact and public appointment updating or deletion |
| 19:31:58 | brr | k-fish: Many wrong login tries should be logged, I think.... And deletion of shared appointments and contacts... If you delete your own contacts / appointments it is not so very important to log that... |
| 19:31:58 | k-fish | canani: what is logged later depends on the module code. |
| 19:32:11 | k|p | tom: huh? |
| 19:32:16 | k-fish | brr: ok. |
| 19:32:54 | k|p | tom : i am a little slow |
| 19:33:11 | tom | ok |
| 19:33:19 | canani | webmail attachments uploads should be logged too |
| 19:33:41 | tom | yes |
| 19:34:15 | brr | Maybe a log regarding how much space each webmail user is using??? |
| 19:34:27 | k|p | this is all up to the programmers, ipso and i will try to create the facilities to do so |
| 19:34:52 | tom | not a log but an overview about all things regarding used disc space |
| 19:35:35 | k-fish | ok. k|p is right, this depends on the module programmer later on. |
| 19:35:38 | k-fish | next topic? |
| 19:35:44 | * k|p agress |
| 19:35:49 | IpSo__ | k|p: ability to log to a file or db or file + db would on a per module, per log level basis be nice as well. :) |
| 19:36:19 | IpSo__ | yes, next topic. :) |
performance tuning
| 19:36:28 | k-fish | 5. performance tuning |
| 19:36:39 | k-fish | this integrates with the last topic |
| 19:37:03 | k-fish | if the logs provide timestamps, code using large amounts of time can be spotted probably. |
| 19:37:20 | k-fish | and the there is database tuning. |
| 19:37:49 | k-fish | someone (i'd have to search my emails for more details) talked to me about looking into adding indexes. |
| 19:38:01 | k-fish | did you know we don't use any indexes yet? it's true... |
| 19:38:06 | IpSo__ | async db queries for things like logs, so the page can still be sent to the user while log entries are taking place? |
| 19:40:33 | k|p | do we want to do performance tuning? |
| 19:41:01 | IpSo__ | k-fish: theres not a single index in the MGW schemas? |
| 19:41:30 | tom | I'm indexing all emails ... |
| 19:41:34 | k-fish | IpSo__: afaik not. some primary keys, which create implicit indexes, but... |
| 19:41:49 | k-fish | tom: ok, so you're the hero if the day :) |
| 19:42:10 | tom | (but only primary keys) |
| 19:42:21 | k-fish | k|p: well, the person i talked to said moregroupware was very slow compared to other apps. |
| 19:42:33 | IpSo__ | obviously, indexes are a must. :) I'm quite surprised to hear this actually. |
| 19:43:08 | k-fish | i can put up a simple patch to enable SQL logging, and we could then EXPLAIN the SQL to find optimization potentials... |
| 19:43:29 | tom | perhaps speed up by using frames ? |
| 19:43:30 | k-fish | i can give this a start for the core parts, but i won't be able to optimize all modules... |
| 19:43:31 | IpSo__ | postgresql has very nice features that can help build proper indexes and make sure they are used. |
| 19:43:35 | k|p | i don't think any db creates keys without indexing them |
| 19:43:43 | k|p | tom : noooooo |
| 19:43:49 | k-fish | but we acces not only keys, that's the problem. |
| 19:44:08 | k-fish | tom: frames: no. the overhead here does *not* come from loading the menu all the time :) |
| 19:44:59 | brr | The webmail2 module is a bit slower than the rest of the modules....... |
| 19:45:10 | k-fish | brr: well, it's rather complex. |
| 19:45:31 | IpSo__ | proper indexes are a must, in even a small table (4000 rows), proper use of indexes can give 5-10x speed improvements |
| 19:45:44 | tom | parsing emails connecting to pop3 / imap / smtp cannot be very fast |
| 19:45:51 | k-fish | ok, i'll give this a start next week, and report the results to the mailing list. ok? |
| 19:46:22 | canani | who said the performance problem is due to database accesses ? |
| 19:46:45 | k-fish | this is likely. there may be other reasons as well, true. |
| 19:46:54 | k-fish | any hints from you on this? experiences? |
| 19:46:56 | tom | smarty ? |
| 19:47:09 | k-fish | probably not. the fastest engine around, afaik |
| 19:47:26 | hondzik | really big tables in html :( |
| 19:47:30 | tom | what about the recompile-option is this always on ? |
| 19:47:31 | k-fish | one can tune the settings for production use, though. |
| 19:47:35 | k|p | the performance problems are probably due to bad program structure and db/query design |
| 19:47:43 | k-fish | tom: that's what i meant :) |
| 19:47:53 | IpSo__ | k-fish: do you know anyone who uses MGW on Postgres in production? They could enable statistics gathering in postgres and it will tell you which tables/indexes are used/not used, could be very useful to quickly squash the slowest areas. |
| 19:48:21 | k-fish | k|p: yep. if we can imporve performace by simple changes SQL table design, we should do this first. |
| 19:48:32 | k-fish | then look at the basic design failures. |
| 19:49:10 | k-fish | hondzik: HTML cleanup needs to be done, true. i did it whenever working on a template, though there still needs work to be done. |
| 19:49:33 | k-fish | Mozilla e.g. is much faster when not working in "quirks mode". this needs clean (X)HTML, though... |
| 19:49:55 | k|p | my log class lets you time parts of code, like: $L->time("name"); while { bla; } $L->time("name") .. a log entry is then created that notes the time taken |
| 19:50:32 | k|p | this will holefully help finding design faults |
| 19:50:51 | k-fish | ok. |
| 19:50:54 | k-fish | next topic? |
| 19:50:58 | k|p | ok |
PHP 4.0.x support
| 19:51:07 | k-fish | 6. PHP 4.0.x support |
| 19:51:48 | k-fish | 20 responses on sf.net survey, 1 using 4.0.x |
| 19:51:57 | k|p | current survey results? (and are they representative?) |
| 19:52:12 | * k|p is too slow |
| 19:52:15 | k-fish | current, yes. representative, who knows? |
| 19:52:23 | IpSo__ | k-fish: regarding my last statement - http://www.postgresql.org/idocs/index.php?monitoring-stats.html |
| 19:52:23 | hondzik | ok |
| 19:52:23 | brr | Will it be possible to get MGW to work really fast? As far as I can manage to understand the biggest problem is limitations in the browser technology.... |
| 19:53:01 | k-fish | IpSo__: noted, will read later :) |
| 19:53:19 | k-fish | brr: in a LAN that should be not too big a problem... |
| 19:53:37 | hondzik | I'm not sure about it, i'm running php4.1.2 but there is probably lot of people usong 4.0.6 |
| 19:53:45 | k-fish | anyway, if we dump 4.0.x support, we can switch to using $_GET and friends... |
| 19:54:04 | k-fish | well, who is running moregroupware anyway? |
| 19:54:25 | k-fish | a) locally, office or sth. probably an admin around, upgradin should be possible. |
| 19:54:50 | k-fish | b) hosted server. most providers run current PHP, due to security fixes. no? |
| 19:55:06 | k|p | b) yes |
| 19:55:08 | hondzik | hopefuly yes |
| 19:55:23 | IpSo__ | yes. |
| 19:55:30 | IpSo__ | <-- works for web hosting company. |
| 19:55:38 | brr | a) => No problems for me.... I can upgrade my three running MGW installations... |
| 19:55:45 | tom | at least 4.1.x |
| 19:56:01 | IpSo__ | we upgrade everytime an exploit is found. :) Otherwise we usually leave it alone. |
| 19:57:02 | k-fish | one comment on the survey was: "Progress means updating"... |
| 19:57:31 | IpSo__ | why would someone _not_ upgrade to at least 4.1? |
| 19:58:21 | hondzik | there is no reason to not update |
| 19:58:30 | brr | IpSo__: Not everyone is freaks like you. I can manage to install a Linux distribution, but not to upgrade PHP.... |
| 19:58:56 | IpSo__ | brr: distro's provide RPMs/debs to upgrade when exploits are found too. |
| 19:58:59 | brr | IpSo__: But I run my three MGW installations at the moment on Windows NT. And at NT I know how to upgrade! |
| 19:59:19 | hondzik | brr: :) |
| 19:59:35 | tom | even SuSE gives updates for 4.1.x for 7.3 |
| 19:59:38 | brr | IpSo__: Hm. Yes. No... I have tried some upgrades. Allways dependencies - problems... |
| 20:00:06 | IpSo__ | brr: yes, thats valid. I suggest apt-rpm. :) |
| 20:00:21 | k|p | brr : but mostly mgw will be installed by a sys admin on the system of his choice ... if he is not the sys admin there will be one around who is able to ungrad it, i think |
| 20:01:04 | brr | No big deal for me... As you have said everyone should run new PHP versions because of security reasons... |
| 20:02:15 | k-fish | ok, so will we dump 4.0.x support then? |
| 20:02:30 | canani | RH provides P{HP upgrades for 7.xx due to security vurnerability. |
| 20:02:32 | k-fish | or shall we ask for votes on the user mailing list first? |
| 20:02:53 | hondzik | we should ask the list |
| 20:03:16 | k-fish | ok, i'll do it. |
| 20:03:30 | k|p | did we not do that with the survey already? |
| 20:03:31 | k-fish | how long should voting be "open" then? |
| 20:03:57 | k-fish | well, i asked what versions were used - not if people would mind dropping support for 4.0.x |
| 20:04:02 | hondzik | till next monday? |
| 20:04:10 | k|p | true |
| 20:04:56 | k-fish | monday - ok. my SQL portability fixes will have to wait until then, I'm afraid. i used $_SESSION all over the place, and only wnat to change that if needed :) |
| 20:05:03 | k-fish | s/wnat/that |
| 20:05:11 | k-fish | s/wnat/want |
| 20:05:17 | * k-fish is confused :) |
| 20:06:46 | k-fish | next topic? |
| 20:07:05 | hondzik | yes, I'll have to go in 20 minutes :( |
error reporting and E_ALL
| 20:07:56 | k-fish | 7. error_reporting E_ALL. hondzik, go ahead. |
| 20:08:09 | k-fish | has been your suggestion, after all :) |
| 20:09:23 | hondzik | I tried to set error_reporting to E_ALL. it makes a lot of warnings in all included files :( |
| 20:09:31 | tom | is E_ALL the same as E_ERROR | E_WARNING | E_PARSE | E_NOTICE ? |
| 20:09:36 | hondzik | like module_exec,... |
| 20:09:52 | hondzik | yes, it's the higher level :)) |
| 20:10:04 | k-fish | most about uninitialized variables, right? |
| 20:10:22 | hondzik | we are using a lot of unitialized variables, especially array indexes |
| 20:10:25 | IpSo__ | I heard warnings do degrade performance... so this could be part of the performance tuning topic? |
| 20:10:37 | k-fish | can mostly be fixed by checking with isset() before using a var, i guess |
| 20:10:45 | k-fish | IpSo__: only if you log those, i guess. |
| 20:10:58 | hondzik | I did'n hear this, but if it's true it's real break |
| 20:11:11 | k-fish | for a production system, i'd set logging to some lower level anyway |
| 20:11:18 | IpSo__ | E_ALL promotes good coding practice too. |
| 20:11:19 | k-fish | hondzik: true. |
| 20:11:24 | k-fish | IpSo__: true :) |
| 20:11:50 | IpSo__ | though, I think I turn E_ALL off in phpGACL... I should double check that. :) |
| 20:12:04 | k-fish | but: do we need some coordinated effort to clean this up, or can we lay this in the hands ot the module coders? |
| 20:12:15 | k-fish | and who takes care of the core code? |
| 20:12:22 | hondzik | E_ALL is too high, but we should decide on some level |
| 20:12:36 | k|p | why is it too high? |
| 20:12:45 | k-fish | without E_ALL i don't get any erros at all, so... |
| 20:12:54 | k|p | i would vote for the coders taking care of it |
| 20:13:08 | k-fish | (aside from really having broken something) |
| 20:13:14 | k-fish | k|p: and the core? |
| 20:13:22 | k-fish | userfunc, etc? |
| 20:13:29 | hondzik | maybe it's not too high, but it'll we a lot of work to fix it :)) |
| 20:13:40 | k-fish | hondzik: would you be willing to do that? ;) |
| 20:13:52 | k|p | hondzik : yes, but it only has to be done once and we're clear |
| 20:13:54 | hondzik | the core and calendar are probably the bigest problems |
| 20:14:07 | hondzik | k|p: right |
| 20:14:11 | --- Notify: newb is offline (brunner.openprojects.net). |
| 20:14:33 | hondzik | in the core is lot of oninicialized indexes in arrays |
| 20:14:39 | brr | Hopefully someone fix the buggy calendar module... I really need a "bug free" calendar! |
| 20:15:20 | hondzik | brr: k-fish did a lot of work on calendar and I'll try to work on it too |
| 20:15:48 | brr | Yes! K-fish has done A GREAT JOB with the calendar. But some bugs still live. Regarding rights. |
| 20:15:58 | k-fish | ok, we can decide on the "who" later, i'd say. |
| 20:16:26 | k-fish | summary: we want to have the code as clean as possible, but fixing severe bugs has higher priority. right? |
| 20:16:30 | hondzik | you're right, but the rights system is more complex problem which we have to discuss |
| 20:16:49 | k-fish | yep, that is the next-but-one topic :) |
| 20:16:56 | --> Li (~Li@j195.mistral.cz) has joined #moregroupware |
XSS exploits, security
| 20:17:01 | k-fish | real quick on 8. XSS exploits |
| 20:17:22 | k-fish | someone suggested to make it possible to restrict access to just the IP that started a session. |
| 20:17:41 | k-fish | i like that idea, and will try to add that to the code. ok? |
| 20:17:51 | tom | a simple checkbox when logging in |
| 20:18:03 | hondzik | i like it too |
| 20:18:04 | k-fish | with a checkbox on the login form, yep, to disable it in case of problems... |
| 20:18:18 | k-fish | ok. anything else on this? |
| 20:18:23 | brr | If you access MGW through a proxy? What will happen??? Will MGW log the real IP or the proxy IP? |
| 20:18:27 | k|p | k-fish : you were against that a while ago because some ppl get new ip's from there providers |
| 20:18:40 | hondzik | maybe it should be in some general settings for admins only |
| 20:18:42 | k-fish | k|p: yep, but if one can disable it when logging in... |
| 20:18:58 | k|p | does anybody know if this ip changing goes any furter than C-subnets? |
| 20:19:05 | k|p | k-fish : thue |
| 20:19:18 | k-fish | hondzik: this way you could either disable or enable it... the other way case to case. |
| 20:19:42 | IpSo__ | k|p: yes it most likely can. |
| 20:19:44 | k-fish | maybe mixing this is possible: the admin can disable disabling of the check when logging in. (clear?) |
| 20:20:04 | hondzik | clear :) |
| 20:20:10 | k-fish | fine :) |
| 20:20:27 | k-fish | i'll write up a proposal and post it to the list. |
| 20:20:29 | IpSo__ | you could do other checks... if IP causes problems. |
| 20:20:36 | k-fish | examples? |
| 20:20:42 | k|p | IpSo__ : ok, pitty :) |
| 20:21:14 | IpSo__ | they might be the greatest, but you could grab the user-agent string + screen res etc... match against those instead perhaps? |
| 20:21:25 | k|p | store session keys in session and recompute them when the session is accessed again |
| 20:22:22 | k-fish | k|p: huh? |
| 20:23:15 | k|p | yes, as ipso proposes, hash that data and store it in session, it should be the same next time round, so when you try to access the session again, the same data is hashed, compared, and if it is the same, you know the same user is accessing the session |
| 20:23:26 | IpSo__ | stats programs grab all kinds of information from the browser... combining as much of that as possible could do the trick if IP's cause problems. |
| 20:24:42 | k|p | does register globals = off fit in here? |
| 20:24:45 | k-fish | ah. ok. |
| 20:25:02 | k-fish | k|p: this should be the goal ASAP, anyway! |
| 20:25:10 | IpSo__ | or use SSL and don't worry about it? |
| 20:25:16 | k-fish | fits better in the next topic... |
| 20:25:27 | k-fish | IpSo__: that is possible anyway. i use it that way. |
| 20:26:20 | k-fish | forgte my "ntext topic" nonsense above... |
| 20:26:43 | k-fish | XSS get's really hard when register_globals is off, yes. |
| 20:27:43 | k-fish | but when someone adds a JS call to some data that is later put into the HTML page, and sends the cookie to some remote server, one still can steal a session. therefore the check on the ip, etc... |
| 20:28:02 | k-fish | but register_globals=off should be possible, true. |
| 20:28:30 | k-fish | ok, 9. rights management now? |
| 20:28:39 | k-fish | or some more on XSS and security? |
| 20:28:56 | k|p | k-fish : but if you use enough data in the session key, the stealer will have a very hard time mimicing it all |
| 20:29:21 | IpSo__ | k|p: yes, its not perfect, but thats the idea. |
| 20:29:35 | * brr does not care so very much about the security as MGW is used only in the LAN at the inside of firewalls. |
| 20:29:42 | IpSo__ | actually... |
| 20:29:56 | IpSo__ | k-fish: every look at zend.com and how they do it? |
| 20:30:18 | k-fish | IpSo__: no. interesting? |
| 20:30:21 | IpSo__ | they don't use SSL at all... but I think they have some nifty challange/response thing setup. |
| 20:30:40 | IpSo__ | clear text passwords aren't sent over the wire... but they don't use SSL. |
| 20:31:03 | IpSo__ | I found it interesting... not sure if it will help us here or not though. |
| 20:31:11 | k-fish | ah. phplib did that for some years. md5 using javascript, and send that over the net. |
| 20:31:35 | k-fish | you can still steal the sent hash when not using SSL, though. |
| 20:31:55 | k-fish | to protect the actual passwords, SSL or IpSec or ... is the way to go. |
| 20:32:01 | IpSo__ | yes, but they use a challange/response to guard against that I think. |
| 20:32:16 | IpSo__ | VNC does something similar too I think. |
| 20:32:21 | k-fish | hm. we should have a look some time. |
| 20:32:47 | k|p | but mgw does not need to be so secure somebody would want to waste loads of processor time thying to decrypt the hash (which is near imposible anyway) |
| 20:33:06 | k|p | s/thying/trying |
| 20:33:17 | hondzik | sorry, I have to leave now:( I will read your discusion tomorow |
| 20:33:24 | k-fish | k|p: true, but if only the hash is sent, then you can inject that without the need to decrypt it. |
| 20:33:25 | --- hondzik is now known as hondzik_logging |
| 20:33:44 | k|p | k-fish : ah, of course :) |
| 20:33:55 | IpSo__ | yes, no decryption needed. |
| 20:34:29 | IpSo__ | again, the "proper" way is to use SSL... but there are alternatives that can work quite well. |
| 20:35:15 | k-fish | next topic? it's getting late... |
| 20:35:51 | k|p | yes, somebody should have told me to have dinner before this meeting :) |
rights management
| 20:36:03 | k-fish | 9. rights management |
| 20:36:20 | k-fish | k|p: those sessions always take longer than you think :) |
| 20:36:40 | k-fish | k|p, IpSo__: your turn, right? |
| 20:37:28 | k|p | nothing from me, go ipso! ... :p |
| 20:38:08 | IpSo__ | well, the gf is out of town for 10 days, so I should have lots of time to work on phpGACL. ;) |
| 20:38:29 | k-fish | ok, to give the others some more info: |
| 20:38:48 | k-fish | IpSo__ works on phpgacl, right? |
| 20:38:57 | k-fish | ah, btw, the survey results: |
| 20:39:07 | IpSo__ | A minor feature release will be coming soon, then hopefully I can try getting a small module in MGW to use it. |
| 20:39:22 | IpSo__ | k-fish: Yes, http://phpgacl.sourceforge.net/ |
| 20:39:55 | k-fish | unix like permissions (rwx) lead with 20/58 |
| 20:40:08 | k-fish | then follows ACL with 19/58 |
| 20:40:22 | k-fish | then current system with 16/58 |
| 20:40:28 | IpSo__ | wow, close. |
| 20:40:57 | k-fish | so the unix rwx system "wins", but i think ACLs would be a better solution. |
| 20:41:06 | IpSo__ | well, ACLs can "mimic" rwx, and I would think the "current system" as well. |
| 20:41:17 | k-fish | as one of you stated, most people know relatively less about ACL systems... |
| 20:41:26 | k-fish | IpSo__: true. |
| 20:41:32 | IpSo__ | in the intrest of not making 19/58 people upset, it might be worth using an ACL system. ;) |
| 20:41:41 | k|p | agree |
| 20:41:46 | k-fish | yep. |
| 20:41:58 | IpSo__ | however... |
| 20:42:07 | IpSo__ | ACL system == much more processing power. |
| 20:42:27 | k-fish | in what sense? |
| 20:42:51 | IpSo__ | well, its much more powerful, so if people start using all its features... |
| 20:43:41 | IpSo__ | now your checking permissions on every contact, or every note, or every appointment for any number of different possible permissions. |
| 20:44:28 | k-fish | ok, but people keep asking for the possibility make an entry only visible for users of a certain group, etc. |
| 20:44:35 | k-fish | so they obviously want those features. |
| 20:44:53 | IpSo__ | right, its a tradeoff of course... but measures can be taken to minimize the disadvantages. |
| 20:45:07 | IpSo__ | I've already added hased directory caching in phpGACL, which greatly improves the performance. |
| 20:45:17 | k-fish | yep. read that... |
| 20:45:27 | k-fish | what else would you suggest? |
| 20:45:43 | IpSo__ | your looking about 5ms per acl_check() that hits the db, and about .5-1ms that hits cache. |
| 20:46:18 | IpSo__ | so, I can see some cases where you would have 1-5 acl_check()'s per "row", or per "contact" |
| 20:46:56 | IpSo__ | so you display 10 contacts to the user, that could be 50 acl_check()'s or about 250ms if all of them hit the db. |
| 20:47:19 | k-fish | not too bad |
| 20:47:43 | tom | what about a directory structure with 500 checks ?? |
| 20:48:04 | k-fish | where would that happen? |
| 20:48:07 | IpSo__ | 500 checks that all hit the cache? 500ms roughly. |
| 20:48:33 | tom | I'm planning rights for public email folder |
| 20:48:57 | IpSo__ | see, a row that has 5 acl_check()'s, usually 90% of those will be the same one each time. |
| 20:48:59 | k-fish | ok, but you would only have to check for the items you actually are going to display. |
| 20:49:44 | k|p | and hence the problem ... you don't know that till after the acl_checks |
| 20:49:57 | k-fish | yep. another thing that comes to my mind: will it still be possible to use ADOdb's paging feature? |
| 20:49:57 | IpSo__ | phpgacl caches in memory, per page load to speed things up even more, so subsequent acl_check()'s that are identical are very light. |
| 20:50:34 | k-fish | or will we have to enhance that to take ACLs into account? |
| 20:50:44 | IpSo__ | k-fish: paging has to be looked in to more, but adodb can be extended so it would work. |
| 20:51:02 | IpSo__ | again though, that is where performance can become an issue too. |
| 20:51:25 | k|p | that would the best solution, but would make upgrading adodb an issue |
| 20:51:54 | IpSo__ | I can't see what we can do about it though, if someone has 1000 contacts that some user _may_ be able to see, we have to check permissions on all 1000 to find out for sure. |
| 20:52:47 | IpSo__ | k|p: not really, adodb is all OO, so I can easily include a class that extends it with phpGACL, I can't see that being much of a problem at this point. |
| 20:53:05 | k-fish | ok. |
| 20:53:26 | IpSo__ | k|p: it should only be a small number of functions, yes there will have to be some maintenance, but I think it would be minor. |
| 20:53:33 | k-fish | IpSo__: do you think you could write a proposal in the next two weeks? |
| 20:53:57 | k-fish | we shouldn't try this before 0.6.6, there are other issues as well. don't mix too much :) |
| 20:54:08 | k-fish | so we have some time for this to prepare. |
| 20:54:14 | IpSo__ | k-fish: I'll see what I can do, I actually have never looked at MGW beyond the online demo. so that will be the first step. :) |
| 20:54:35 | k-fish | well, don't be shocked :) |
| 20:54:38 | IpSo__ | k-fish: when is 0.6.6 scheduled to release? |
| 20:55:02 | IpSo__ | and which module do you think would be the easiest/best to test phpGACL on? |
| 20:55:06 | k-fish | IpSo__: there is no scheduled date yet. after the changes to SQL have stabilized enough... |
| 20:55:34 | k-fish | IpSo__: easiest probably notes or todo, most useful probably contacts |
| 20:56:01 | IpSo__ | k-fish: okay, in the coming weeks I will see what I can do and keep you all updated. |
| 20:56:12 | k-fish | ok, more on this? |
| 20:56:15 | brr | Hm. Will the new rights part solve bug # 613245? |
| 20:56:50 | k-fish | yep, this should be fixed along the way... |
finishing...
| 20:57:33 | k-fish | next (last) topic: module API |
| 20:57:37 | k-fish | a broad issue... |
| 20:58:22 | k-fish | and probably makes sense to talk about that after things like module manager demands, rights, etc. have been discussed more in depth... |
| 20:58:23 | k-fish | or? |
| 20:58:41 | k-fish | k|p_: do you have some plans for a new overview module? |
| 20:59:04 | k|p | k-fish : only plans |
| 20:59:05 | k-fish | this would be another prerequisite for a module API: how to provide overview functions |
| 20:59:26 | k-fish | ok, so i guess we can shift the module API topic on to a later IRC session. opinions? |
| 20:59:34 | k|p | that would be the main issue |
| 20:59:52 | k|p | fine with me ... we have much to do anyway :p |
| 21:00:05 | k-fish | true :) |
| 21:00:26 | k-fish | ok, thank you everybody for joining tonight. |
| 21:00:52 | k-fish | as promsied i'll summarize the session, i can't promise to do it this week, though... |
| 21:01:01 | k|p | np |
| 21:01:24 | tom | f-fish: thank YOU for leading this session |
| 21:01:48 | k-fish | tom: you are welcome :) |
| 21:01:53 | tom | s/f-/k- |
| 21:02:03 | k-fish | :) |
| 21:02:30 | k-fish | ok, i declare open discussion now :) have fun... |
| 21:02:33 | k|p | happy coding everybody :) |
| 21:05:02 | <-- tom has quit ("Leaving") |
| 21:05:05 | k|p | IpSo__ : talk to you next week about logging |
| 21:05:15 | k|p | bye all |
| 21:05:23 | k-fish | bye |
| 21:06:18 | --- You have left channel #moregroupware ("good night...") |