Re: Virtual Domain Solution
On Friday 7 July 2000, at 14 h 48, the keyboard of Ryan Hayle <[EMAIL PROTECTED]> wrote: > What is the best solution for > ISP hosting of virtual domains? Are there any integrated packages > which can handle web/email/ftp access on a per-domain, per-user > basis? I don't know (see Webmin) but I do not find it necessary. > Right now, I am using exim for email, with gnu-pop3d and the virtual > domains patch. I am adding each virtual domain to the apache config > manually, and then to the exim config, storing everything in > /virtual/domain.com. I'm not even getting into FTP access. There > must be a better way to do this. At the present time, I do it by hand (with the help of M4, for instance to be sure all "mandatory" email addresses such as abuse, root, postmaster, etc, appear for every mail domain). In the future, when it will become unbearable, I suggest the following solution: - design a SQL database will all the info about customers/members (do they have a Web site, what is the name of their virtual domain, what are the contacts, etc), - produce the flat text files of the various software from this database. That way, you don't have to find SQL-aware versions of all the programs you use. > Unfortunately, I've also got to try to train > NT-monkeys to do this, and so I need some type of GUI or web interface, It is relatively easy to update a database through the Web. You can develop it yourself. > In general, however do most ISP's simply go and write custom scripts for > everything? Yes, specially in the Internet business, which is moving fast. New requirments pop up every day.
Re: Virtual Domain Solution
On Friday 7 July 2000, at 14 h 48, the keyboard of Ryan Hayle <[EMAIL PROTECTED]> wrote: > What is the best solution for > ISP hosting of virtual domains? Are there any integrated packages > which can handle web/email/ftp access on a per-domain, per-user > basis? I don't know (see Webmin) but I do not find it necessary. > Right now, I am using exim for email, with gnu-pop3d and the virtual > domains patch. I am adding each virtual domain to the apache config > manually, and then to the exim config, storing everything in > /virtual/domain.com. I'm not even getting into FTP access. There > must be a better way to do this. At the present time, I do it by hand (with the help of M4, for instance to be sure all "mandatory" email addresses such as abuse, root, postmaster, etc, appear for every mail domain). In the future, when it will become unbearable, I suggest the following solution: - design a SQL database will all the info about customers/members (do they have a Web site, what is the name of their virtual domain, what are the contacts, etc), - produce the flat text files of the various software from this database. That way, you don't have to find SQL-aware versions of all the programs you use. > Unfortunately, I've also got to try to train > NT-monkeys to do this, and so I need some type of GUI or web interface, It is relatively easy to update a database through the Web. You can develop it yourself. > In general, however do most ISP's simply go and write custom scripts for > everything? Yes, specially in the Internet business, which is moving fast. New requirments pop up every day. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Virtual Domain Solution
Hi All, I (we) are writing some customized additions to Webmin for ISPs. We should be finished in about 2 weeks. Send me a request if you want to be on the beta trial and can commit to giving us some feed back so we can get it to release by Aug 15. Larry At 06:38 PM 7/7/00 -0500, Ryan Hayle wrote: >Yes, that approach makes a lot of sense--what I was asking was whether some >such system exists already. Unfortunately, I've also got to try to train >NT-monkeys to do this, and so I need some type of GUI or web interface, >which was why I was considering qmail, and the qmailadmin program. I guess >I'm just looking for some simple solution to avoid having to write and do >all of this myself. Definitely an area where Linux is lacking...perhaps it >is something I could work on--a Debian-specific solution of some kind.
RE: Virtual Domain Solution
Hi All, I (we) are writing some customized additions to Webmin for ISPs. We should be finished in about 2 weeks. Send me a request if you want to be on the beta trial and can commit to giving us some feed back so we can get it to release by Aug 15. Larry At 06:38 PM 7/7/00 -0500, Ryan Hayle wrote: >Yes, that approach makes a lot of sense--what I was asking was whether some >such system exists already. Unfortunately, I've also got to try to train >NT-monkeys to do this, and so I need some type of GUI or web interface, >which was why I was considering qmail, and the qmailadmin program. I guess >I'm just looking for some simple solution to avoid having to write and do >all of this myself. Definitely an area where Linux is lacking...perhaps it >is something I could work on--a Debian-specific solution of some kind. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Virtual Domain Solution
On Sat, Jul 08, 2000 at 04:11:03AM +0300, [EMAIL PROTECTED] wrote: > > > On Fri, 7 Jul 2000 [EMAIL PROTECTED] wrote: > > > Our system is build around mysql and an ncurses interface. It's really > > just selecting account records and passing arguments to perl scripts. > > The front office can register domains, add users, change passwords, > > install mailmaps and so forth. Trust me, they are not technical. :^) > > > We definetaly need somethin general like this for Linux/Unix - > web/ftp/mail system based on some SQL database, with good interface - from > this point, any other interface could be writtenthe problem is, > everybody designs it for himself and never releases it, just because it > wouldn't be of any use to anyone else And because it's the gnarliest, most patched, most incomplete and ill conceived piece of legacy mission critical software running on their system they are embarrassed to show it to anyone, let alone support it. Just speaking from my experience. ;^) cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Database publishing, e-commerce, office/internet integration, Debian linux.
Re: Virtual Domain Solution
On Sat, Jul 08, 2000 at 04:11:03AM +0300, [EMAIL PROTECTED] wrote: > > > On Fri, 7 Jul 2000 [EMAIL PROTECTED] wrote: > > > Our system is build around mysql and an ncurses interface. It's really > > just selecting account records and passing arguments to perl scripts. > > The front office can register domains, add users, change passwords, > > install mailmaps and so forth. Trust me, they are not technical. :^) > > > We definetaly need somethin general like this for Linux/Unix - > web/ftp/mail system based on some SQL database, with good interface - from > this point, any other interface could be writtenthe problem is, > everybody designs it for himself and never releases it, just because it > wouldn't be of any use to anyone else And because it's the gnarliest, most patched, most incomplete and ill conceived piece of legacy mission critical software running on their system they are embarrassed to show it to anyone, let alone support it. Just speaking from my experience. ;^) cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Database publishing, e-commerce, office/internet integration, Debian linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Virtual Domain Solution
On Sat, 8 Jul 2000, Mike Bennett wrote: > > - The small ones do it all manually. This is a nightmare as numbers grow. Something like I did, a little script here and there, various things configured such that it is easier to copy and paste than work out the programming logic, with hard coded IP Addresses, Modem Identifiers Accounting Info/etc. all over the place in our own mix of applications. > > "Add a new domain and virtual web server". > > > > The software could handle that. They don't necessarily need to know that > > this > > task involves manipulating DNS zone files and adding a virtual host entry > > to a > > web server. The software should handle those real things. On Fri, 7 Jul 2000 [EMAIL PROTECTED] wrote: > That's really not too hard. Tedious yes because there are endless > things to do. And we've been at it seven years. > > Our system is build around mysql and an ncurses interface. It's really > just selecting account records and passing arguments to perl scripts. > The front office can register domains, add users, change passwords, > install mailmaps and so forth. Trust me, they are not technical. :^) I've followed the same approach using a Web Page interface. The Admin guys are really just making MySQL database entries. System programs (those scripts :-) read the data and do the dirty work. Some programs are run through cron ... or I get an email request. Log what gets done when. > I can share with you our huge mistake: we started with account=unix userid. > Don't do that! Now we have master accounts that have secondary accounts; > those may have any number of services attached. 100% solid advise. Have your system generate a unique ID for a new account to use as a primary DB key and tie all your account records to it. Permanently retire the ID when the account laspses. Let your accounting people worry about whether or not accounts are paid and you worry about keeping the service records in sync with the accounting ones. --- Gerard MacNeil, P. Eng [EMAIL PROTECTED] System Administrator Supercity Internet Services http://www.supercity.ns.ca
Re: Virtual Domain Solution
On Fri, 7 Jul 2000 [EMAIL PROTECTED] wrote: > Our system is build around mysql and an ncurses interface. It's really > just selecting account records and passing arguments to perl scripts. > The front office can register domains, add users, change passwords, > install mailmaps and so forth. Trust me, they are not technical. :^) > We definetaly need somethin general like this for Linux/Unix - web/ftp/mail system based on some SQL database, with good interface - from this point, any other interface could be writtenthe problem is, everybody designs it for himself and never releases it, just because it wouldn't be of any use to anyone else > I can share with you our huge mistake: we started with account=unix userid. > Don't do that! Now we have master accounts that have secondary accounts; I think everybody with more than 1000 users has seen this...
Re: Virtual Domain Solution
> > Then program to that conceptual model so that the staff only interact with > that > model, manipulating it to do what they want. The software should then handle > the > "real" systems underneath to produce the result that they want. > > For example, they might want to: > > "Add a new domain and virtual web server". > > The software could handle that. They don't necessarily need to know that this > task involves manipulating DNS zone files and adding a virtual host entry to a > web server. The software should handle those real things. That's really not too hard. Tedious yes because there are endless things to do. And we've been at it seven years. Our system is build around mysql and an ncurses interface. It's really just selecting account records and passing arguments to perl scripts. The front office can register domains, add users, change passwords, install mailmaps and so forth. Trust me, they are not technical. :^) It is the accounting system too, so all the account data is there. You need that. DO also invest in designing libraries. When you change those the whole thing goes to hell. And yes, there is always something broken because you are always changing. Every system is different; it is unlikely you will find much in common with someone elses system. I can share with you our huge mistake: we started with account=unix userid. Don't do that! Now we have master accounts that have secondary accounts; those may have any number of services attached. Billing, master and secondary accounts all have their own contact information; so do some of the services. Probably elementary to an accounting person but a rough lesson for us. cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Database publishing, e-commerce, office/internet integration, Debian linux.
RE: Virtual Domain Solution
Ryan, On Fri, 7 Jul 2000, Ryan Hayle wrote: ryan > Yes, that approach makes a lot of sense--what I was asking was whether some ryan > such system exists already. Unfortunately, I've also got to try to train ryan > NT-monkeys to do this, and so I need some type of GUI or web interface, ryan > which was why I was considering qmail, and the qmailadmin program. I guess ryan > I'm just looking for some simple solution to avoid having to write and do ryan > all of this myself. Definitely an area where Linux is lacking...perhaps it ryan > is something I could work on--a Debian-specific solution of some kind. ryan > ryan > In general, however do most ISP's simply go and write custom scripts for ryan > everything? Or do they just do it manually? I've only got about 10 domains ryan > right now, but once we get more, I can easily imagine a nightmarish ryan > situation--forgetting one file, setting one permission wrong, or something. I know, that's how our little ISP started. We understood that the key to success would be software, software software. As far as I know, and speaking very generally: - The large ones ( Thousands of virtual hosts ) essentially employ a person who's job it is to look after just one aspect, ie DNS server, Web servers, mail relays etc. There is enough work in just each area to keep someone ( or perhaps a whole "division") occupied. They get a large software supplier/systems integrator like Sun, Microsoft, IBM etc. to write software systems for them. - The medium ones (hundreds-thousands of virtual hosts) Develop their own systems, scripts, procedures in-house. I would class siliconBLUE in here. There is often a significant investment in the software developed and these, after all, are commercial organisations that will want to make some return on that investment. They won't generally put their software in the public domain because: 1. They have a signicant investment in software development that they will want to recover. 2. They won't want to give away any competitive edge. - The small ones do it all manually. This is a nightmare as numbers grow. I am a complete supporter of public domain software and I particularly like the Debian approach. Most of the GUI type tools I have seen, though, tend to be just a GUI interface on the front of existing processes and systems. They don't actually add much and the user still needs to know most of the technicalities of what they are doing. If you are going to write software for front desk "monkeys" (no disrespect intended) then you need to think about a conceptual layer/model/paradigm that is above the technicalities, that your staff can understand in whole. Then program to that conceptual model so that the staff only interact with that model, manipulating it to do what they want. The software should then handle the "real" systems underneath to produce the result that they want. For example, they might want to: "Add a new domain and virtual web server". The software could handle that. They don't necessarily need to know that this task involves manipulating DNS zone files and adding a virtual host entry to a web server. The software should handle those real things. Cheers Mike ryan > ryan > ryan > ryan > Thanks, ryan > Ryan ryan > ryan > > -Original Message- ryan > > From: Jeremy C. Reed [mailto:[EMAIL PROTECTED] ryan > > Sent: Friday, 07 July, 2000 3:19 PM ryan > > To: Ryan Hayle ryan > > Cc: 'debian-isp@lists.debian.org' ryan > > Subject: Re: Virtual Domain Solution ryan > > ryan > > ryan > > On Fri, 7 Jul 2000, Ryan Hayle wrote: ryan > > ryan > > > This is an overly general question, but I've found very little info ryan > > > on this so I thought I would ask here. What is the best ryan > > solution for ryan > > > ISP hosting of virtual domains? Are there any integrated packages ryan > > > which can handle web/email/ftp access on a per-domain, per-user ryan > > > basis? ryan > > ryan > > Do you need websites for all of your users? ryan > > ryan > > > Right now, I am using exim for email, with gnu-pop3d and the virtual ryan > > > domains patch. I am adding each virtual domain to the apache config ryan > > > manually, and then to the exim config, storing everything in ryan > > > /virtual/domain.com. I'm not even getting into FTP access. There ryan > > > must be a better way to do this. ryan > > ryan > > What do you mean by a "better way"? Is it because you are ryan > > doing all the ryan > > setups manually with each step one a
RE: Virtual Domain Solution
On Sat, 8 Jul 2000, Mike Bennett wrote: > > - The small ones do it all manually. This is a nightmare as numbers grow. Something like I did, a little script here and there, various things configured such that it is easier to copy and paste than work out the programming logic, with hard coded IP Addresses, Modem Identifiers Accounting Info/etc. all over the place in our own mix of applications. > > "Add a new domain and virtual web server". > > > > The software could handle that. They don't necessarily need to know that this > > task involves manipulating DNS zone files and adding a virtual host entry to a > > web server. The software should handle those real things. On Fri, 7 Jul 2000 [EMAIL PROTECTED] wrote: > That's really not too hard. Tedious yes because there are endless > things to do. And we've been at it seven years. > > Our system is build around mysql and an ncurses interface. It's really > just selecting account records and passing arguments to perl scripts. > The front office can register domains, add users, change passwords, > install mailmaps and so forth. Trust me, they are not technical. :^) I've followed the same approach using a Web Page interface. The Admin guys are really just making MySQL database entries. System programs (those scripts :-) read the data and do the dirty work. Some programs are run through cron ... or I get an email request. Log what gets done when. > I can share with you our huge mistake: we started with account=unix userid. > Don't do that! Now we have master accounts that have secondary accounts; > those may have any number of services attached. 100% solid advise. Have your system generate a unique ID for a new account to use as a primary DB key and tie all your account records to it. Permanently retire the ID when the account laspses. Let your accounting people worry about whether or not accounts are paid and you worry about keeping the service records in sync with the accounting ones. --- Gerard MacNeil, P. Eng [EMAIL PROTECTED] System Administrator Supercity Internet Services http://www.supercity.ns.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Virtual Domain Solution
Yes, that approach makes a lot of sense--what I was asking was whether some such system exists already. Unfortunately, I've also got to try to train NT-monkeys to do this, and so I need some type of GUI or web interface, which was why I was considering qmail, and the qmailadmin program. I guess I'm just looking for some simple solution to avoid having to write and do all of this myself. Definitely an area where Linux is lacking...perhaps it is something I could work on--a Debian-specific solution of some kind. In general, however do most ISP's simply go and write custom scripts for everything? Or do they just do it manually? I've only got about 10 domains right now, but once we get more, I can easily imagine a nightmarish situation--forgetting one file, setting one permission wrong, or something. Thanks, Ryan > -Original Message- > From: Jeremy C. Reed [mailto:[EMAIL PROTECTED] > Sent: Friday, 07 July, 2000 3:19 PM > To: Ryan Hayle > Cc: 'debian-isp@lists.debian.org' > Subject: Re: Virtual Domain Solution > > > On Fri, 7 Jul 2000, Ryan Hayle wrote: > > > This is an overly general question, but I've found very little info > > on this so I thought I would ask here. What is the best > solution for > > ISP hosting of virtual domains? Are there any integrated packages > > which can handle web/email/ftp access on a per-domain, per-user > > basis? > > Do you need websites for all of your users? > > > Right now, I am using exim for email, with gnu-pop3d and the virtual > > domains patch. I am adding each virtual domain to the apache config > > manually, and then to the exim config, storing everything in > > /virtual/domain.com. I'm not even getting into FTP access. There > > must be a better way to do this. > > What do you mean by a "better way"? Is it because you are > doing all the > setups manually with each step one at a time? You may want to > make some > scripts to automate your steps. > > I think you just need a few scripts: > > 1) add a new domain script > a) add zone info for dns > b) add "domain-name" to your mail local deliveries file > (maybe in your > case: /etc/virtual/domains) > c) add a user to Unix password database (/etc/passwd) for the > website/webmaster > d) create home and html directories for the webmaster/website > e) add container to httpd config > f) create directory for virtual mail users (maybe: > /etc/virtual/domainname) > g) create mail spool directory for the domain (maybe: > /var/spool/virtual/domainname) > h) create passwd file and alias file for virtual mail users > (maybe with > a default webmaster entry) > i) if needed, add ftp info (in my situation, ftpd is > already setup and > no changes are needed for adding new domains) > j) reload httpd > k) reload dns > l) test dns,ftp,smtp,pop3,http > > 2) add to virtual aliases > > 3) add a new virtual user (with password) for email > > And maybe scripts to remove domain and real user (webmaster) from all > configs, and to remove aliases and users from virtual passwd files. > > Jeremy C. Reed > http://www.reedmedia.net > http://bsd.reedmedia.net > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] >
Re: Virtual Domain Solution
On Fri, 7 Jul 2000 [EMAIL PROTECTED] wrote: > Our system is build around mysql and an ncurses interface. It's really > just selecting account records and passing arguments to perl scripts. > The front office can register domains, add users, change passwords, > install mailmaps and so forth. Trust me, they are not technical. :^) > We definetaly need somethin general like this for Linux/Unix - web/ftp/mail system based on some SQL database, with good interface - from this point, any other interface could be writtenthe problem is, everybody designs it for himself and never releases it, just because it wouldn't be of any use to anyone else > I can share with you our huge mistake: we started with account=unix userid. > Don't do that! Now we have master accounts that have secondary accounts; I think everybody with more than 1000 users has seen this... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Virtual Domain Solution
> > Then program to that conceptual model so that the staff only interact with that > model, manipulating it to do what they want. The software should then handle the > "real" systems underneath to produce the result that they want. > > For example, they might want to: > > "Add a new domain and virtual web server". > > The software could handle that. They don't necessarily need to know that this > task involves manipulating DNS zone files and adding a virtual host entry to a > web server. The software should handle those real things. That's really not too hard. Tedious yes because there are endless things to do. And we've been at it seven years. Our system is build around mysql and an ncurses interface. It's really just selecting account records and passing arguments to perl scripts. The front office can register domains, add users, change passwords, install mailmaps and so forth. Trust me, they are not technical. :^) It is the accounting system too, so all the account data is there. You need that. DO also invest in designing libraries. When you change those the whole thing goes to hell. And yes, there is always something broken because you are always changing. Every system is different; it is unlikely you will find much in common with someone elses system. I can share with you our huge mistake: we started with account=unix userid. Don't do that! Now we have master accounts that have secondary accounts; those may have any number of services attached. Billing, master and secondary accounts all have their own contact information; so do some of the services. Probably elementary to an accounting person but a rough lesson for us. cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Database publishing, e-commerce, office/internet integration, Debian linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Virtual Domain Solution
Ryan, On Fri, 7 Jul 2000, Ryan Hayle wrote: ryan > Yes, that approach makes a lot of sense--what I was asking was whether some ryan > such system exists already. Unfortunately, I've also got to try to train ryan > NT-monkeys to do this, and so I need some type of GUI or web interface, ryan > which was why I was considering qmail, and the qmailadmin program. I guess ryan > I'm just looking for some simple solution to avoid having to write and do ryan > all of this myself. Definitely an area where Linux is lacking...perhaps it ryan > is something I could work on--a Debian-specific solution of some kind. ryan > ryan > In general, however do most ISP's simply go and write custom scripts for ryan > everything? Or do they just do it manually? I've only got about 10 domains ryan > right now, but once we get more, I can easily imagine a nightmarish ryan > situation--forgetting one file, setting one permission wrong, or something. I know, that's how our little ISP started. We understood that the key to success would be software, software software. As far as I know, and speaking very generally: - The large ones ( Thousands of virtual hosts ) essentially employ a person who's job it is to look after just one aspect, ie DNS server, Web servers, mail relays etc. There is enough work in just each area to keep someone ( or perhaps a whole "division") occupied. They get a large software supplier/systems integrator like Sun, Microsoft, IBM etc. to write software systems for them. - The medium ones (hundreds-thousands of virtual hosts) Develop their own systems, scripts, procedures in-house. I would class siliconBLUE in here. There is often a significant investment in the software developed and these, after all, are commercial organisations that will want to make some return on that investment. They won't generally put their software in the public domain because: 1. They have a signicant investment in software development that they will want to recover. 2. They won't want to give away any competitive edge. - The small ones do it all manually. This is a nightmare as numbers grow. I am a complete supporter of public domain software and I particularly like the Debian approach. Most of the GUI type tools I have seen, though, tend to be just a GUI interface on the front of existing processes and systems. They don't actually add much and the user still needs to know most of the technicalities of what they are doing. If you are going to write software for front desk "monkeys" (no disrespect intended) then you need to think about a conceptual layer/model/paradigm that is above the technicalities, that your staff can understand in whole. Then program to that conceptual model so that the staff only interact with that model, manipulating it to do what they want. The software should then handle the "real" systems underneath to produce the result that they want. For example, they might want to: "Add a new domain and virtual web server". The software could handle that. They don't necessarily need to know that this task involves manipulating DNS zone files and adding a virtual host entry to a web server. The software should handle those real things. Cheers Mike ryan > ryan > ryan > ryan > Thanks, ryan > Ryan ryan > ryan > > -Original Message- ryan > > From: Jeremy C. Reed [mailto:[EMAIL PROTECTED]] ryan > > Sent: Friday, 07 July, 2000 3:19 PM ryan > > To: Ryan Hayle ryan > > Cc: '[EMAIL PROTECTED]' ryan > > Subject: Re: Virtual Domain Solution ryan > > ryan > > ryan > > On Fri, 7 Jul 2000, Ryan Hayle wrote: ryan > > ryan > > > This is an overly general question, but I've found very little info ryan > > > on this so I thought I would ask here. What is the best ryan > > solution for ryan > > > ISP hosting of virtual domains? Are there any integrated packages ryan > > > which can handle web/email/ftp access on a per-domain, per-user ryan > > > basis? ryan > > ryan > > Do you need websites for all of your users? ryan > > ryan > > > Right now, I am using exim for email, with gnu-pop3d and the virtual ryan > > > domains patch. I am adding each virtual domain to the apache config ryan > > > manually, and then to the exim config, storing everything in ryan > > > /virtual/domain.com. I'm not even getting into FTP access. There ryan > > > must be a better way to do this. ryan > > ryan > > What do you mean by a "better way"? Is it because you are ryan > > doing all the ryan > > setups manually with each step one at a time? You m
RE: Virtual Domain Solution
Yes, that approach makes a lot of sense--what I was asking was whether some such system exists already. Unfortunately, I've also got to try to train NT-monkeys to do this, and so I need some type of GUI or web interface, which was why I was considering qmail, and the qmailadmin program. I guess I'm just looking for some simple solution to avoid having to write and do all of this myself. Definitely an area where Linux is lacking...perhaps it is something I could work on--a Debian-specific solution of some kind. In general, however do most ISP's simply go and write custom scripts for everything? Or do they just do it manually? I've only got about 10 domains right now, but once we get more, I can easily imagine a nightmarish situation--forgetting one file, setting one permission wrong, or something. Thanks, Ryan > -Original Message- > From: Jeremy C. Reed [mailto:[EMAIL PROTECTED]] > Sent: Friday, 07 July, 2000 3:19 PM > To: Ryan Hayle > Cc: '[EMAIL PROTECTED]' > Subject: Re: Virtual Domain Solution > > > On Fri, 7 Jul 2000, Ryan Hayle wrote: > > > This is an overly general question, but I've found very little info > > on this so I thought I would ask here. What is the best > solution for > > ISP hosting of virtual domains? Are there any integrated packages > > which can handle web/email/ftp access on a per-domain, per-user > > basis? > > Do you need websites for all of your users? > > > Right now, I am using exim for email, with gnu-pop3d and the virtual > > domains patch. I am adding each virtual domain to the apache config > > manually, and then to the exim config, storing everything in > > /virtual/domain.com. I'm not even getting into FTP access. There > > must be a better way to do this. > > What do you mean by a "better way"? Is it because you are > doing all the > setups manually with each step one at a time? You may want to > make some > scripts to automate your steps. > > I think you just need a few scripts: > > 1) add a new domain script > a) add zone info for dns > b) add "domain-name" to your mail local deliveries file > (maybe in your > case: /etc/virtual/domains) > c) add a user to Unix password database (/etc/passwd) for the > website/webmaster > d) create home and html directories for the webmaster/website > e) add container to httpd config > f) create directory for virtual mail users (maybe: > /etc/virtual/domainname) > g) create mail spool directory for the domain (maybe: > /var/spool/virtual/domainname) > h) create passwd file and alias file for virtual mail users > (maybe with > a default webmaster entry) > i) if needed, add ftp info (in my situation, ftpd is > already setup and > no changes are needed for adding new domains) > j) reload httpd > k) reload dns > l) test dns,ftp,smtp,pop3,http > > 2) add to virtual aliases > > 3) add a new virtual user (with password) for email > > And maybe scripts to remove domain and real user (webmaster) from all > configs, and to remove aliases and users from virtual passwd files. > > Jeremy C. Reed > http://www.reedmedia.net > http://bsd.reedmedia.net > > > -- > 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: Virtual Domain Solution
On Fri, 7 Jul 2000, Ryan Hayle wrote: > This is an overly general question, but I've found very little info > on this so I thought I would ask here. What is the best solution for > ISP hosting of virtual domains? Are there any integrated packages > which can handle web/email/ftp access on a per-domain, per-user > basis? Do you need websites for all of your users? > Right now, I am using exim for email, with gnu-pop3d and the virtual > domains patch. I am adding each virtual domain to the apache config > manually, and then to the exim config, storing everything in > /virtual/domain.com. I'm not even getting into FTP access. There > must be a better way to do this. What do you mean by a "better way"? Is it because you are doing all the setups manually with each step one at a time? You may want to make some scripts to automate your steps. I think you just need a few scripts: 1) add a new domain script a) add zone info for dns b) add "domain-name" to your mail local deliveries file (maybe in your case: /etc/virtual/domains) c) add a user to Unix password database (/etc/passwd) for the website/webmaster d) create home and html directories for the webmaster/website e) add container to httpd config f) create directory for virtual mail users (maybe: /etc/virtual/domainname) g) create mail spool directory for the domain (maybe: /var/spool/virtual/domainname) h) create passwd file and alias file for virtual mail users (maybe with a default webmaster entry) i) if needed, add ftp info (in my situation, ftpd is already setup and no changes are needed for adding new domains) j) reload httpd k) reload dns l) test dns,ftp,smtp,pop3,http 2) add to virtual aliases 3) add a new virtual user (with password) for email And maybe scripts to remove domain and real user (webmaster) from all configs, and to remove aliases and users from virtual passwd files. Jeremy C. Reed http://www.reedmedia.net http://bsd.reedmedia.net
Re: Virtual Domain Solution
On Fri, 7 Jul 2000, Ryan Hayle wrote: > I'm considering moving to qmail, with the vchkpw/vpopmail program, > and (hopefully) qmailadmin, although I have not been able to get this > to work successfully. What solutions or approaches have other people > taken? the way i'm doing this is exim, qpopper with the sql auth patch and proftpd. all three are able to use sql, so i store my customers info in an sql table. for the moment, apache is being done by hand from a flat file, but i'm considering moving to mod_mass_vhost (alas i'm not sure it will worth for me as i don't have lots of clients), but the other tasks are handled by the before mentioned triad very well. to bad i've been lazy to create some frontend so i'm still doing the config stuff by hand, but it's in one place.. easy to maintain, easy to backup, easy to restore, i like it :) -- [-] there's a devil waiting outside your door ... and just what the hell was i doing before i got so rudely interrupted ?
Re: Virtual Domain Solution
On Fri, 7 Jul 2000, Ryan Hayle wrote: > This is an overly general question, but I've found very little info > on this so I thought I would ask here. What is the best solution for > ISP hosting of virtual domains? Are there any integrated packages > which can handle web/email/ftp access on a per-domain, per-user > basis? Do you need websites for all of your users? > Right now, I am using exim for email, with gnu-pop3d and the virtual > domains patch. I am adding each virtual domain to the apache config > manually, and then to the exim config, storing everything in > /virtual/domain.com. I'm not even getting into FTP access. There > must be a better way to do this. What do you mean by a "better way"? Is it because you are doing all the setups manually with each step one at a time? You may want to make some scripts to automate your steps. I think you just need a few scripts: 1) add a new domain script a) add zone info for dns b) add "domain-name" to your mail local deliveries file (maybe in your case: /etc/virtual/domains) c) add a user to Unix password database (/etc/passwd) for the website/webmaster d) create home and html directories for the webmaster/website e) add container to httpd config f) create directory for virtual mail users (maybe: /etc/virtual/domainname) g) create mail spool directory for the domain (maybe: /var/spool/virtual/domainname) h) create passwd file and alias file for virtual mail users (maybe with a default webmaster entry) i) if needed, add ftp info (in my situation, ftpd is already setup and no changes are needed for adding new domains) j) reload httpd k) reload dns l) test dns,ftp,smtp,pop3,http 2) add to virtual aliases 3) add a new virtual user (with password) for email And maybe scripts to remove domain and real user (webmaster) from all configs, and to remove aliases and users from virtual passwd files. Jeremy C. Reed http://www.reedmedia.net http://bsd.reedmedia.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Virtual Domain Solution
On Fri, 7 Jul 2000, Ryan Hayle wrote: > I'm considering moving to qmail, with the vchkpw/vpopmail program, > and (hopefully) qmailadmin, although I have not been able to get this > to work successfully. What solutions or approaches have other people > taken? the way i'm doing this is exim, qpopper with the sql auth patch and proftpd. all three are able to use sql, so i store my customers info in an sql table. for the moment, apache is being done by hand from a flat file, but i'm considering moving to mod_mass_vhost (alas i'm not sure it will worth for me as i don't have lots of clients), but the other tasks are handled by the before mentioned triad very well. to bad i've been lazy to create some frontend so i'm still doing the config stuff by hand, but it's in one place.. easy to maintain, easy to backup, easy to restore, i like it :) -- [-] there's a devil waiting outside your door ... and just what the hell was i doing before i got so rudely interrupted ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
