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
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
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 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
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
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
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
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 ryanThis is an overly general question, but I've found very little info ryanon this so I thought I would ask here. What is the best ryan solution for ryanISP hosting of virtual domains? Are there any integrated packages ryanwhich can handle web/email/ftp access on a per-domain, per-user ryanbasis? ryan ryan Do you need websites for all of your users? ryan ryanRight now, I am using exim for email, with gnu-pop3d and the virtual ryandomains patch. I am adding each virtual domain to the apache config ryanmanually, and then to the exim config, storing everything in ryan/virtual/domain.com. I'm not even getting into FTP access. There ryanmust 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 may want to ryan make some ryan scripts to automate your steps. ryan ryan I think you just need a few scripts: ryan ryan 1) add a new domain script ryan a) add zone info for dns ryan b) add domain-name to your mail local deliveries file ryan (maybe in your ryancase: /etc/virtual/domains) ryan c) add a user to Unix password database (/etc/passwd) for the ryanwebsite/webmaster ryan d) create home
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
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
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
