Re: Webmail - considerations...
http://packages.debian.org/testing/libs/libc-client4.7.html The above is a c client library for imap written by the University of Washington (not sure, but I don't think that package is the latest version but you can get the source from UW if you want). vector - Original Message - From: "Jeremy Lunn" <[EMAIL PROTECTED]> To: "Przemyslaw Wegrzyn" <[EMAIL PROTECTED]> Cc: "Russell Coker" <[EMAIL PROTECTED]>; ; Sent: Tuesday, June 12, 2001 7:03 AM Subject: Re: Webmail - considerations... > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > Of course, I know... > > But our middle-tier will be developed using C++ , AFAIK. > > That's why I asked about c-client library... > > I would be pretty surprised if there is no c library for IMAP as well. > > -- > Jeremy Lunn > Melbourne, Australia > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re[2]: CGI Errors
Hey Marcel, print "Content-Type: text/html\n\n"; is the one you want. -- Kevin
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > Of course, I know... > > But our middle-tier will be developed using C++ , AFAIK. > > That's why I asked about c-client library... > > I would be pretty surprised if there is no c library for IMAP as well. Sure, but I'd like to check if there are any alternatives to c-client. IMHO it's poorly documented. Probably I need to dig its source code... -=Czaj-nick=-
Re: user privileges with php (like with suexec)
On Tue, Jun 12, 2001 at 12:12:13PM +0200, Marcel Hicking wrote: > On 12 Jun 2001, at 1:21, Jeremy Lunn wrote: > > > I am wondering what is the best way to get simular results > > to suexec with php? > > > > I've heard of people running seperate instances of apache > > for each client. Is that likely to be a messy solution? > > how much overhead would each instance be? > > You will need a separate IP adresse for each apache instance. > Not a solution, usually. You could run processes on different ports (one of the proposed solutions for a problem of the same stripe with mod_perl). This might be as unacceptable though. -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpjx5olP4PNa.pgp Description: PGP signature
Re: Webmail - considerations...
http://packages.debian.org/testing/libs/libc-client4.7.html The above is a c client library for imap written by the University of Washington (not sure, but I don't think that package is the latest version but you can get the source from UW if you want). vector - Original Message - From: "Jeremy Lunn" <[EMAIL PROTECTED]> To: "Przemyslaw Wegrzyn" <[EMAIL PROTECTED]> Cc: "Russell Coker" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Sent: Tuesday, June 12, 2001 7:03 AM Subject: Re: Webmail - considerations... > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > Of course, I know... > > But our middle-tier will be developed using C++ , AFAIK. > > That's why I asked about c-client library... > > I would be pretty surprised if there is no c library for IMAP as well. > > -- > Jeremy Lunn > Melbourne, Australia > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 01:26:09PM +0200, Przemyslaw Wegrzyn wrote: > > Thanx, I didn't know this feature... Acctually, I'm not so familiar with > > IMAP protocol yet... > > Depending what language you use you won't need to know the IMAP > protocol. Things like perl and php have IMAP modules. Of course, I know... But our middle-tier will be developed using C++ , AFAIK. That's why I asked about c-client library... -=Czaj-nick=-
Re[2]: CGI Errors
Hey Marcel, print "Content-Type: text/html\n\n"; is the one you want. -- Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Tue, Jun 12, 2001 at 01:26:09PM +0200, Przemyslaw Wegrzyn wrote: > Thanx, I didn't know this feature... Acctually, I'm not so familiar with > IMAP protocol yet... Depending what language you use you won't need to know the IMAP protocol. Things like perl and php have IMAP modules. -- Jeremy Lunn Melbourne, Australia
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > > Of course, I know... > > But our middle-tier will be developed using C++ , AFAIK. > > That's why I asked about c-client library... > > I would be pretty surprised if there is no c library for IMAP as well. Sure, but I'd like to check if there are any alternatives to c-client. IMHO it's poorly documented. Probably I need to dig its source code... -=Czaj-nick=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: user privileges with php (like with suexec)
On Tue, Jun 12, 2001 at 12:12:13PM +0200, Marcel Hicking wrote: > On 12 Jun 2001, at 1:21, Jeremy Lunn wrote: > > > I am wondering what is the best way to get simular results > > to suexec with php? > > > > I've heard of people running seperate instances of apache > > for each client. Is that likely to be a messy solution? > > how much overhead would each instance be? > > You will need a separate IP adresse for each apache instance. > Not a solution, usually. You could run processes on different ports (one of the proposed solutions for a problem of the same stripe with mod_perl). This might be as unacceptable though. -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton PGP signature
Re: CGI Errors
Bart-Jan Vrielink <[EMAIL PROTECTED]> 12 Jun 2001, at 12:04: > On Tue, 12 Jun 2001, Ritesh Goel wrote: > > > I have a script which runs fine from the UNIX shell. As soon as I > > try going thru the browser, I get an error which says - "Premature > > end of Script Header". What should i do or what can i do ?? > > It looks like the script does not produce any valid HTTP headers. As a > minimum it should produce a line 'Content-Type: text/html' (or any > other content-type) and a blank line, before the html begins. So that's print "Content-Type: text/html\n\n"; or print "Content-Type: text/plain\n\n"; ;-)
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Russell Coker wrote: > Another thing, do the webmail systems use directory notifications? With > directory notifications the application can be informed by the kernel > when new files are created. The IMAP protocol supports announcing new > mail to the client. If the mail store and the webmail system are on > separate machines then IMAP is the only way to avoid polling for new mail > (AFAIK directory notifications don't work over NFS). Thanx, I didn't know this feature... Acctually, I'm not so familiar with IMAP protocol yet... > So now you're planning to write your own webmail program? Yes, we need some nonusuall features... > I suggest that when a user logs in they get an IMAP connection. An > option to have the IMAP connection timeout and be closed before the > webmail system times out (webmail timeout on no activity should be long > like 30 minutes while IMAP timeout should be 10 minutes at most) would be > handy, but isn't required. But generally IMAP connections should stay > open for the duration of the session. That's as I see it, thanx.. All the actual logic will be implemented in the middle tier daemon(s). -=Czaj-nick=-
Re: Webmail - considerations...
On Tue, Jun 12, 2001 at 02:59:00PM +0200, Przemyslaw Wegrzyn wrote: > Of course, I know... > But our middle-tier will be developed using C++ , AFAIK. > That's why I asked about c-client library... I would be pretty surprised if there is no c library for IMAP as well. -- Jeremy Lunn Melbourne, Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 01:26:09PM +0200, Przemyslaw Wegrzyn wrote: > > Thanx, I didn't know this feature... Acctually, I'm not so familiar with > > IMAP protocol yet... > > Depending what language you use you won't need to know the IMAP > protocol. Things like perl and php have IMAP modules. Of course, I know... But our middle-tier will be developed using C++ , AFAIK. That's why I asked about c-client library... -=Czaj-nick=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: user privileges with php (like with suexec)
On 12 Jun 2001, at 19:52, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 11:37:38AM +0200, Marcel Hicking > wrote: > Unfortunatelly you cannot set user/group in your > apache > config within a virtual host. The user/group > directives > once again will only affect cgi programs when > set for vhosts. > > Probably this is more an apache than a > PHP issue? > > Would it be possible at all for Apache to run a small part > of it with root privileges? Say just enough to fork > non-root processes. If this approach could be implemented > somehow you'd still want to apply a lot of the same checks > as suexec does. Not as far as I know. A feature I'm missing badly in Apache... Cheers, Marcel -- __ .´ `. : :' ! Enjoy `. `´ Debian/GNU Linux `-
Re: Webmail - considerations...
On Tue, Jun 12, 2001 at 01:26:09PM +0200, Przemyslaw Wegrzyn wrote: > Thanx, I didn't know this feature... Acctually, I'm not so familiar with > IMAP protocol yet... Depending what language you use you won't need to know the IMAP protocol. Things like perl and php have IMAP modules. -- Jeremy Lunn Melbourne, Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: user privileges with php (like with suexec)
On 12 Jun 2001, at 1:21, Jeremy Lunn wrote: > I am wondering what is the best way to get simular results > to suexec with php? > > I've heard of people running seperate instances of apache > for each client. Is that likely to be a messy solution? > how much overhead would each instance be? You will need a separate IP adresse for each apache instance. Not a solution, usually. > The other solution is to use the CGI version of php and use > suexec. I still don't think this is as nice as just using > the the php module. > > Have I missed any solutions? > > Although I'm reluctant to hack any code that would be > running as root, would it be possible to hack php to pass > pages to child proceses owned by the same user as the php > file and if none exist create one? I'll agree with that, the cgi version does not integrate as smoothly as the module version. But since the module version runs under the same uid as the apache process itself (well, it actually can be considered part of the process) it won't have the necessary rights to su. Unfortunatelly you cannot set user/group in your apache config within a virtual host. The user/group directives once again will only affect cgi programs when set for vhosts. Probably this is more an apache than a PHP issue? Cheers, Marcel -- __ .´ `. : :' ! Enjoy `. `´ Debian/GNU Linux `-
Re: CGI Errors
On Tue, 12 Jun 2001, Ritesh Goel wrote: > I have a script which runs fine from the UNIX shell. As soon as I try > going thru the browser, I get an error which says - "Premature end of > Script Header". What should i do or what can i do ?? It looks like the script does not produce any valid HTTP headers. As a minimum it should produce a line 'Content-Type: text/html' (or any other content-type) and a blank line, before the html begins. -- Tot ziens, Bart-Jan
CGI Errors
Hi I have a script which runs fine from the UNIX shell. As soon as I try going thru the browser, I get an error which says - "Premature end of Script Header". What should i do or what can i do ?? Thanks, Ritesh Goel
Re: Virtual Domains & LDAP
On Friday 08 June 2001 19:56, Kevin J. Menard, Jr. wrote: > What would be the best structure for this? > > I was thinking something like: > > o = my_organization -- domain1 > -- domain2 > -- domainN > -- Admins -- LDAP Admin > -- Users > > I figured lumping all the users together would make it easier for > searches, since there would only be one base. > > However, I was also thinking of something like this: > > o = my_organization -- domain1 -- Users > -- domain2 -- Users > -- domainN -- Users > -- Admins -- LDAP Admin > > With this system, I figured each domain could be within its own > namespace, and I like this approach better, due to the more natural > organization of things. However, being split up like that, I would > think searches would be agonizingly slow. No, searches would be fast. For each user you will have an attribute that you will use as the key for your searches, typically uid or cn. If you do a search for "uid=user_company.com" then it'll require a single search operation on a single index which should be quite fast. Searching for the complete DN of "uid=user_company.com, ou=company.com, o=my_org" is also a single search of a single index. Searching for "uid=user_company.com" with a search base of "ou=company.com, o=my_org" requires searching through two indexes which isn't as fast. But if the uid attribute has a unique value (which it will have if it is the user-name concatenated with the company name) then you can just search by the attribute value. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Finding the Bottleneck
On Monday 11 June 2001 10:51, Jason Lim wrote: > Too bad this is a production system or I would try it. I've never tried > reiserFS (neither has anyone else here) so we might test it along with > a 2.4 kernel later. I hear 2.4 has intergrated reiserFS support? 2.4 has integrated ReiserFS support. ReiserFS primarily boosts performance when you have large numbers of small files in a directory (as a heavily loaded outbound mail server does). However when all data is being sync'd all the time (as a mail queue is) then ReiserFS does not perform so well and may deliver less performance than Ext2. One significant benefit of ReiserFS is that it is journalled and does not require a lengthy fsck operation after a power failure. I would not recommend that you change to ReiserFS at this time. All my most important data is on ReiserFS and I am quite confidant in the combination of the reliability of ReiserFS (which is not 100% but is getting close) and the quality of my backups. However changing the file system type on a server is a serious operation, I suggest that you play with ReiserFS on some less important machines and then consider using it on servers once you've got a feel for it. > From: "Alson van der Meulen" <[EMAIL PROTECTED]> > > > not help (even hindered) by reiserFS. Don't flame me if I'm wrong > > > as I haven't done huge amounts of research into this, but this is > > > just what I've heard. > > > > I know at least for news servers, reiserfs can be quite faster, > > so I guess it might be faster for mail too... > > > > There's really one way to be sure: test it ;) -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Webmail - considerations...
On Sunday 10 June 2001 17:16, Przemyslaw Wegrzyn wrote: > 1. Almost every available webmail system uses the following way of > handling (rreceiving, in this example) attachements: load the whole > message body from IMAP server or message file, decode it and send to > the client. > The _whole_ attachement gets loaded into server's RAM. Isn't it waste > of resources/ killing the server ? > I think it should read/decode/send the attachement on a line-by-line > (or part-by-part generaly) manner. Am I right ? That depends what your average message size is. If you have some unlikely situation such as people using the webmail system for no other purpose than to send messages with Word documents attached then that would be a serious performance issue. However my experience is that average message sizes tend to be around 10K to 20K. When you consider the overhead of an Apache process, the kernel buffers for a connected socket, the data used for the PHP or Perl interpreter, etc then 20K of message probably isn't a large proportion of the memory in use for the connection. > 2. Which one is better - accessing maildirs directly, or using IMAP ? > I can see that IMAP seems to be more scalable / universal... Maildirs > probably can be much faster to work with directly, but probably less > secure... > Any other pros/contras ? One issue is that when using IMAP the WebMail system can consider that anyone with the correct credentials to connect to IMAP can access the account. That means that all the password checking code is in the IMAP and POP servers. If you access the Maildir directly then it's a third place. Another thing, do the webmail systems use directory notifications? With directory notifications the application can be informed by the kernel when new files are created. The IMAP protocol supports announcing new mail to the client. If the mail store and the webmail system are on separate machines then IMAP is the only way to avoid polling for new mail (AFAIK directory notifications don't work over NFS). > 3. I'm going to develop the front-end using Apache::ASP or php, not > decided yet, and access the mails through the middle-tier daemon. > The question is - is it a good way to use persistent IMAP connections ? > If so, there will be no overhead of authentication on every operation, > but there can be many open IMAP connections to the local imap server > (probably Courier-IMAP) at the same time. > Which strategy is better ? So now you're planning to write your own webmail program? I suggest that when a user logs in they get an IMAP connection. An option to have the IMAP connection timeout and be closed before the webmail system times out (webmail timeout on no activity should be long like 30 minutes while IMAP timeout should be 10 minutes at most) would be handy, but isn't required. But generally IMAP connections should stay open for the duration of the session. Good luck! -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: CGI Errors
Bart-Jan Vrielink <[EMAIL PROTECTED]> 12 Jun 2001, at 12:04: > On Tue, 12 Jun 2001, Ritesh Goel wrote: > > > I have a script which runs fine from the UNIX shell. As soon as I > > try going thru the browser, I get an error which says - "Premature > > end of Script Header". What should i do or what can i do ?? > > It looks like the script does not produce any valid HTTP headers. As a > minimum it should produce a line 'Content-Type: text/html' (or any > other content-type) and a blank line, before the html begins. So that's print "Content-Type: text/html\n\n"; or print "Content-Type: text/plain\n\n"; ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Tue, 12 Jun 2001, Russell Coker wrote: > Another thing, do the webmail systems use directory notifications? With > directory notifications the application can be informed by the kernel > when new files are created. The IMAP protocol supports announcing new > mail to the client. If the mail store and the webmail system are on > separate machines then IMAP is the only way to avoid polling for new mail > (AFAIK directory notifications don't work over NFS). Thanx, I didn't know this feature... Acctually, I'm not so familiar with IMAP protocol yet... > So now you're planning to write your own webmail program? Yes, we need some nonusuall features... > I suggest that when a user logs in they get an IMAP connection. An > option to have the IMAP connection timeout and be closed before the > webmail system times out (webmail timeout on no activity should be long > like 30 minutes while IMAP timeout should be 10 minutes at most) would be > handy, but isn't required. But generally IMAP connections should stay > open for the duration of the session. That's as I see it, thanx.. All the actual logic will be implemented in the middle tier daemon(s). -=Czaj-nick=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: user privileges with php (like with suexec)
On 12 Jun 2001, at 19:52, Jeremy Lunn wrote: > On Tue, Jun 12, 2001 at 11:37:38AM +0200, Marcel Hicking > wrote: > Unfortunatelly you cannot set user/group in your > apache > config within a virtual host. The user/group > directives > once again will only affect cgi programs when > set for vhosts. > > Probably this is more an apache than a > PHP issue? > > Would it be possible at all for Apache to run a small part > of it with root privileges? Say just enough to fork > non-root processes. If this approach could be implemented > somehow you'd still want to apply a lot of the same checks > as suexec does. Not as far as I know. A feature I'm missing badly in Apache... Cheers, Marcel -- __ .´ `. : :' ! Enjoy `. `´ Debian/GNU Linux `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: user privileges with php (like with suexec)
On 12 Jun 2001, at 1:21, Jeremy Lunn wrote: > I am wondering what is the best way to get simular results > to suexec with php? > > I've heard of people running seperate instances of apache > for each client. Is that likely to be a messy solution? > how much overhead would each instance be? You will need a separate IP adresse for each apache instance. Not a solution, usually. > The other solution is to use the CGI version of php and use > suexec. I still don't think this is as nice as just using > the the php module. > > Have I missed any solutions? > > Although I'm reluctant to hack any code that would be > running as root, would it be possible to hack php to pass > pages to child proceses owned by the same user as the php > file and if none exist create one? I'll agree with that, the cgi version does not integrate as smoothly as the module version. But since the module version runs under the same uid as the apache process itself (well, it actually can be considered part of the process) it won't have the necessary rights to su. Unfortunatelly you cannot set user/group in your apache config within a virtual host. The user/group directives once again will only affect cgi programs when set for vhosts. Probably this is more an apache than a PHP issue? Cheers, Marcel -- __ .´ `. : :' ! Enjoy `. `´ Debian/GNU Linux `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CGI Errors
On Tue, 12 Jun 2001, Ritesh Goel wrote: > I have a script which runs fine from the UNIX shell. As soon as I try > going thru the browser, I get an error which says - "Premature end of > Script Header". What should i do or what can i do ?? It looks like the script does not produce any valid HTTP headers. As a minimum it should produce a line 'Content-Type: text/html' (or any other content-type) and a blank line, before the html begins. -- Tot ziens, Bart-Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: colocation space/inexpensive bandwidth
My company has a data center in Minneapolis. I'm just an internal Unix guy doing billing and Unix'y stuff so you'll have to talk to sales or someone knowledgeable about our pricing to get more info. www.inflow.com Nashville is the next closet to places on your list... On Tue, Jun 05, 2001 at 12:00:40PM -0400, Jeff S Wheeler wrote: > Since we're on the topic of colocation space this morning, I thought I would > post and ask if anyone has colocation cabinet space available at a Level(3) > or similar facility. Currently we colocate with a small ISP and are very > happy with their service, but we would like to be able to offer better > pricing to our customers. However, when last I spoke with L(3) sales folks, > their cabinets were 1000$/mo, with an added 2000$/mo minimum expenditure on > bandwidth/private line services per cabinet. This is too much for us, but > if someone has a few U available someplace that prices bandwidth in the > 400$/Mbit or less range, I would be very interested in consuming that extra > space (for a fee, of course) and taking advantage of your bandwidth pricing. > :-) > > Anyone near Minneapolis/Chicago/Louisville/Cincinnati would be preferable as > well, as currently we maintain our own equipment, and have no need to trust > a pair of "remote hands" to know what they are doing. In those areas we can > continue to have this benefit. > > - jsw > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Nate Duehr <[EMAIL PROTECTED]> GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2 Public Key available upon request, or at wwwkeys.pgp.net and others.
CGI Errors
Hi I have a script which runs fine from the UNIX shell. As soon as I try going thru the browser, I get an error which says - "Premature end of Script Header". What should i do or what can i do ?? Thanks, Ritesh Goel
Re: Virtual Domains & LDAP
On Friday 08 June 2001 19:56, Kevin J. Menard, Jr. wrote: > What would be the best structure for this? > > I was thinking something like: > > o = my_organization -- domain1 > -- domain2 > -- domainN > -- Admins -- LDAP Admin > -- Users > > I figured lumping all the users together would make it easier for > searches, since there would only be one base. > > However, I was also thinking of something like this: > > o = my_organization -- domain1 -- Users > -- domain2 -- Users > -- domainN -- Users > -- Admins -- LDAP Admin > > With this system, I figured each domain could be within its own > namespace, and I like this approach better, due to the more natural > organization of things. However, being split up like that, I would > think searches would be agonizingly slow. No, searches would be fast. For each user you will have an attribute that you will use as the key for your searches, typically uid or cn. If you do a search for "uid=user_company.com" then it'll require a single search operation on a single index which should be quite fast. Searching for the complete DN of "uid=user_company.com, ou=company.com, o=my_org" is also a single search of a single index. Searching for "uid=user_company.com" with a search base of "ou=company.com, o=my_org" requires searching through two indexes which isn't as fast. But if the uid attribute has a unique value (which it will have if it is the user-name concatenated with the company name) then you can just search by the attribute value. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding the Bottleneck
On Monday 11 June 2001 10:51, Jason Lim wrote: > Too bad this is a production system or I would try it. I've never tried > reiserFS (neither has anyone else here) so we might test it along with > a 2.4 kernel later. I hear 2.4 has intergrated reiserFS support? 2.4 has integrated ReiserFS support. ReiserFS primarily boosts performance when you have large numbers of small files in a directory (as a heavily loaded outbound mail server does). However when all data is being sync'd all the time (as a mail queue is) then ReiserFS does not perform so well and may deliver less performance than Ext2. One significant benefit of ReiserFS is that it is journalled and does not require a lengthy fsck operation after a power failure. I would not recommend that you change to ReiserFS at this time. All my most important data is on ReiserFS and I am quite confidant in the combination of the reliability of ReiserFS (which is not 100% but is getting close) and the quality of my backups. However changing the file system type on a server is a serious operation, I suggest that you play with ReiserFS on some less important machines and then consider using it on servers once you've got a feel for it. > From: "Alson van der Meulen" <[EMAIL PROTECTED]> > > > not help (even hindered) by reiserFS. Don't flame me if I'm wrong > > > as I haven't done huge amounts of research into this, but this is > > > just what I've heard. > > > > I know at least for news servers, reiserfs can be quite faster, > > so I guess it might be faster for mail too... > > > > There's really one way to be sure: test it ;) -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Webmail - considerations...
On Sunday 10 June 2001 17:16, Przemyslaw Wegrzyn wrote: > 1. Almost every available webmail system uses the following way of > handling (rreceiving, in this example) attachements: load the whole > message body from IMAP server or message file, decode it and send to > the client. > The _whole_ attachement gets loaded into server's RAM. Isn't it waste > of resources/ killing the server ? > I think it should read/decode/send the attachement on a line-by-line > (or part-by-part generaly) manner. Am I right ? That depends what your average message size is. If you have some unlikely situation such as people using the webmail system for no other purpose than to send messages with Word documents attached then that would be a serious performance issue. However my experience is that average message sizes tend to be around 10K to 20K. When you consider the overhead of an Apache process, the kernel buffers for a connected socket, the data used for the PHP or Perl interpreter, etc then 20K of message probably isn't a large proportion of the memory in use for the connection. > 2. Which one is better - accessing maildirs directly, or using IMAP ? > I can see that IMAP seems to be more scalable / universal... Maildirs > probably can be much faster to work with directly, but probably less > secure... > Any other pros/contras ? One issue is that when using IMAP the WebMail system can consider that anyone with the correct credentials to connect to IMAP can access the account. That means that all the password checking code is in the IMAP and POP servers. If you access the Maildir directly then it's a third place. Another thing, do the webmail systems use directory notifications? With directory notifications the application can be informed by the kernel when new files are created. The IMAP protocol supports announcing new mail to the client. If the mail store and the webmail system are on separate machines then IMAP is the only way to avoid polling for new mail (AFAIK directory notifications don't work over NFS). > 3. I'm going to develop the front-end using Apache::ASP or php, not > decided yet, and access the mails through the middle-tier daemon. > The question is - is it a good way to use persistent IMAP connections ? > If so, there will be no overhead of authentication on every operation, > but there can be many open IMAP connections to the local imap server > (probably Courier-IMAP) at the same time. > Which strategy is better ? So now you're planning to write your own webmail program? I suggest that when a user logs in they get an IMAP connection. An option to have the IMAP connection timeout and be closed before the webmail system times out (webmail timeout on no activity should be long like 30 minutes while IMAP timeout should be 10 minutes at most) would be handy, but isn't required. But generally IMAP connections should stay open for the duration of the session. Good luck! -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: colocation space/inexpensive bandwidth
My company has a data center in Minneapolis. I'm just an internal Unix guy doing billing and Unix'y stuff so you'll have to talk to sales or someone knowledgeable about our pricing to get more info. www.inflow.com Nashville is the next closet to places on your list... On Tue, Jun 05, 2001 at 12:00:40PM -0400, Jeff S Wheeler wrote: > Since we're on the topic of colocation space this morning, I thought I would > post and ask if anyone has colocation cabinet space available at a Level(3) > or similar facility. Currently we colocate with a small ISP and are very > happy with their service, but we would like to be able to offer better > pricing to our customers. However, when last I spoke with L(3) sales folks, > their cabinets were 1000$/mo, with an added 2000$/mo minimum expenditure on > bandwidth/private line services per cabinet. This is too much for us, but > if someone has a few U available someplace that prices bandwidth in the > 400$/Mbit or less range, I would be very interested in consuming that extra > space (for a fee, of course) and taking advantage of your bandwidth pricing. > :-) > > Anyone near Minneapolis/Chicago/Louisville/Cincinnati would be preferable as > well, as currently we maintain our own equipment, and have no need to trust > a pair of "remote hands" to know what they are doing. In those areas we can > continue to have this benefit. > > - jsw > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Nate Duehr <[EMAIL PROTECTED]> GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2 Public Key available upon request, or at wwwkeys.pgp.net and others. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
