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.
Christopher F. Miller, Publisher firstname.lastname@example.org
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
Database publishing, e-commerce, office/internet integration, Debian linux.