These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Cannot reinstall Domains after deletion on the new forum.
Hi Joe, Thought I'd give you a day off.............. :-)
I deleted all of the domains except fablor.net on my Server and attempted to do clean re-installs. System would not allow as they were already existing.(still)
They do not show up under Vservers list.
Cheers?
John John Rigby (Also broke the old thread- was getting large!)
woops!
Forgot to include the rror message:
Error
Failed to create virtual server : The DNS domain arkadyr.com is already hosted by your DNS server
Curioser and curioser said the cat:
Just found I can FTP in with CUTEFTP to all of the "deleted" domains....
Himagain
Hey John,
Not curious at all. You just opted to remove the domains from control of Virtualmin--not delete them. This leaves all of the files, DNS records, etc. in place. The option you checked on the Delete Server page is labeled "Only remove server from Virtualmin's control, and leave website, users and databases untouched". Leaving this unchecked is what you really wanted to do.
In other words: Works as advertised. But I guess the label for that checkbox isn't clear enough about what it's for.
The old domain data will have to be cleaned up manually now, as Virtualmin doesn't know anything about them anymore.
It's too late for me to think straight on telling you everything you need to do to do that...but I'll cover the necessary steps in the morning.
--
Check out the forum guidelines!
Ha there Joe,
I went back over what I did and the destructions are clear - even I wouldn't have done that. :-)
I even got the same problem after doing a new install.
Hey John,
Hmmm...Could be a bug, but I'm sure we'd have heard something by now about it. I'll drop in in the morning and have a look.
--
Check out the forum guidelines!
Hi Joe,
Looks like you've not been in for a look, yet.
So I reloaded fablor.com with no problem - using the VM automagic default Domain setup and all seems well - except it setup a strange alias of fablor.com under fablor.net: fablor.fablor.net.
However it again refused to reinstall netcapitalisation.
Can't find any logical start point in docs for my onging problems, but I now have some JV committments partners that can't believe how long it is taking to get the system online.
So, I have had to setup yet another alternative Shared System in case we can't get this long-term problem resolved soon - and the whole transaction took me less than one hour from go-to-whoa under Cpanel including existing account transfers.
I mention this only to demonstrate that even as a definite non-tech-head, it isn't really a major user-fault at my end.
These are Vmin operational problems.
So, I really need you to resolve it for me/future users, as soon as you can.
Cheers,
John
Hey John,
Nope, you're right, I haven't had a chance to stop by, but will before I post this response.
In the meantime:
<i>So I reloaded fablor.com with no problem - using the VM automagic default Domain setup and all seems well - except it setup a strange alias of fablor.com under fablor.net: fablor.fablor.net.</i>
This isn't strange at all. Here's the FAQ:
http://www.virtualmin.com/faq/one-faq?faq_id=1511#51247
And a forum thread with further discussion:
http://www.virtualmin.com/forums/message-view?message%5fid=50603
I'm pretty sure there's even a thread with you and me talking about it too, several months ago, but I don't see it on a cursory search. You can turn it off, if you don't like it (I'm pretty sure I turned it on for you after our discussion about the issue). ;-)
<i>Can't find any logical start point in docs for my onging problems, but I now have some JV committments partners that can't believe how long it is taking to get the system online.</i>
The problem is that your DNS zones were left behind after server deletion, and it is not something that you should ever see, thus not something that needs documentation. Bugs need fixing, not documenting.
That said, I couldn't reproduce it just now, so I'm going to assume there was a bug in the past in Virtualmin that led to zones being setup somehow differently. Removing the zones in the Webmin BIND module allowed me to create domains...and those new domains, when deleted, do not have any old data sticking around.
In other words: Everything is working as advertised (though I see that something did go wrong on your deletions before--I just don't know what, as it isn't happening now).
<i>So, I have had to setup yet another alternative Shared System in case we can't get this long-term problem resolved soon - and the whole transaction took me less than one hour from go-to-whoa under Cpanel including existing account transfers.</i>
I'll take this opportunity to re-iterate our refund policy: If you aren't entirely satisfied that we're doing a great job both in our software and support, we'll happily refund your purchase price, and you can apply that $99 to the $450 cPanel purchase price. ;-)
<i>So, I really need you to resolve it for me/future users, as soon as you can.</i>
It appears to be resolved. Again, I suspect it was a bug present in much earlier versions of Virtualmin (the one you were running when you created the domains to begin with), that is no longer present. There have been lots of bugs fixed during our Early Adopter period, which is why we're being so nice to our Early Adopters--free license extensions, 50% discounted purchase price, and unlimited support (which, admittedly, does sometimes take 24 hours or so).
Also, please remember that we <i>still</i> aren't claiming that Virtualmin is anything other than Early Adopter beta quality software (it's getting pretty damned good, and I think we're now only a month or so away from ending EA, but we're still not claiming perfection). So, "ongoing problems" are pretty much exactly what you signed up for when you chose to join us during this Early Adopter period, particularly so very <i>early</i> in the Early Adopter period. ;-)
Anyway, if you run into this problem again, please file a bug and we'll get it taken care of as fast as possible.
--
Check out the forum guidelines!
Ha Joe,
First, I would like to reiterate that I think for a one-man operation that you do an excellent job.
Having said that, my messages are all with best intent, NOBODY has more sympathy than I do for the "support" position.
Having been forced to run/design large support functions in my earlier days, I certainly offer pointers with Vmin evolution in mind. I can SEE the potential.
The principal problem is simply structural positioning.
The product is geek-oriented in all respects, but especially in PRE-support.
The most critical aspect in designing a Support Function is to layer it, or as I named it some 20 years ago: Stepped Escalation.
A bit difficult in your one-man situation! :-)
So, what we need here is more User-2-User support, via[b>appointed Mentors/Guides.</b>
(A better design Bulletin Board would do wonders.):-)
The single biggest problem with owning happy support structures is to rapidly identify the source: Bug or Operator/User.
Users love to "catch the product out". It is even good psychology to employ: User involvement.
Still works with me after all these years! :-)
Vis: A Bug Report is really the result of either:
1. Mature/experienced user results.
2. Common experience of multiple users.
Support is where the user is unsure of the cause of the problem:
1. His inexperience
2. The product (Beta!!)
This is first stop and needs a QUICK response. Nothing is worse than that uncertainty.
Here is our weakest point in Vmin now.
"Mature" User volunteers desperately needed.! :-)
Having said all o'that:
-----------------
<i>
it setup a strange alias of fablor.com under fablor.net: fablor.fablor.net.
This isn't strange at all. Here's the FAQ:
http://www.virtualmin.com/faq/one-faq?faq_id=1511#51247
</i>
Right. I'll turn it off, I think.
<i>Bugs need fixing, not documenting.
</i>
Yeah, it's identifying the difference (as above)
<i>I'll take this opportunity to re-iterate our refund policy: If you aren't entirely satisfied that we're doing a great job both in our software and support, we'll happily refund your purchase price.[/i>
Thanks Joe, you did offer that before and I did say then what I've said here today.
The key is timeliness of response. I have actually wasted a loooot of hours on Vmin bugs already, assuming it was me.
Okay, it is really still a Beta situation, I knew that last year when I signed on, but it has been a bit painful and a bit long.
Which brings me to the last point:
I noted the upgrade comment you've posted 18/10:
Sounds like I should re-install as I've still nothing to lose, what do you think?
Cheers,
John
Hey John,
<i>First, I would like to reiterate that I think for a one-man operation that you do an excellent job.</i>
Two-man operation, actually. And Jamie is worth a half dozen good men in every regard. So it's just like a seven person team. ;-)
<i>So, what we need here is more User-2-User support, via appointed Mentors/Guides.
(A better design Bulletin Board would do wonders.):-)</i>
I definitely agree. Thus the reason for our Early Adopter period. We're trying to build a reasonable, intelligent, and capable user base, <i>before</i> inviting in the unwashed masses...ahem...I mean non-technical users, via advertising (we haven't advertised at all--all sales are via word of mouth right now). During this early phase, we're only trying to connect with existing Webmin and Virtualmin users and folks who are willing to take the time to experiment with us on how this thing ought to work. We don't want to gain a reputation for writing obtuse and complex Open Source inspired software...so we've given ourselves time to correct the issues with coming from an Open Source project.
We've also been spending this year (about six months longer than intended, because we're kind of perfectionists) making sure that bugs are few and far between. I believe we're pretty much there--the number of bug reports has gone down remarkably in the past three months or so, despite our active userbase doubling every couple of months. These days the vast majority of issues are with ease of use, failures of documentation, or missing features (which I don't feel too bad about--we'll never be able to implement every feature everyone ever thought about, and we've already outpaced all competitors on almost every front on the three F's: features, functionality, and flexibility...our problem now is far more one of not confusing users with all of those features and options).
I also agree on the quality of the forums package leaving a bit to be desired. OpenACS is not bad, but there are better packages out there. And I have already begun work on migrating our website to a different CMS which features a somewhat more powerful forums package and a simpler but friendlier bug tracker. I'm not sure that the better forum package will increase the involvement of our current crop of expert users, but it might.
<i>I noted the upgrade comment you've posted 18/10:
Sounds like I should re-install as I've still nothing to lose, what do you think?</i>
On no, not again, I beg you! ;-)
Seriously, nothing in the new install.sh or virtualmin-base is going to behave differently from what I've configured manually on your system--the changes were simply to make things that people had to do anyway, like firewall rules and changing some configuration options, happen by default. I promise. If you have any issues at all right now, they will also exist identically in a fresh install. Really.
I'll also point out that nearly everything that happens during install can also occur during upgrades. So, a yum update will install the additional dependencies introduced in this new version (mod_fcgid is the big new change on that front, though it isn't quite supported by Virtualmin), and you don't need to do any re-installing. To be blunt, running install.sh is for systems that don't already have Virtualmin, and nothing else. Re-installing is never the best way to proceed on correcting issues. Tell us about issues and we'll tell you how to correct them <i>without</i> reinstalling.
So, if you have <i>any</i> issues right now, tell me and we'll fix them--reinstalling will not do anything but waste your time. I do not know of any current problems with your system, but you seem to believe there are still problems. You're gonna have to tell me what they are, as you haven't reported any other problems than the one with faulty deletion of DNS zones which has been corrected.
So, don't do it!
Frankly, install.sh is the crappiest and buggiest part of our product. You don't want to use it anymore than you have to. It's pretty new, and has to work with pretty serious limitations. It has to run with a very minimum of services, as it must be able to bootstrap a minimal system into useability--in the short term, it does just check for Perl, but in the next release it will handle installation of Perl if it is not available, so it has to be in shell script rather than a proper language, and we can't even assume we have a good shell like bash so it has to use old sh constructs.
So, again, don't do it! Use the good tools, like Webmin and Virtualmin and our assistance in the forums and customer issues tracker and the bug tracker, to correct problems, not the crappy install.sh (which won't fix anything and will take up time unnecessarily).
Hmmm...can I say "don't do it!" some other way? I really don't want you to re-install again. Just tell me about issues, if you have any, and we'll get them fixed.
--
Check out the forum guidelines!
Ha there Joe,
So it would appear that perhaps you really, really don't want me to reinstall hmmnnn??? :-)
But this Announcement sounded soooooo goood:
<i> Oct 18, 2006
New virtualmin-base package on Red Hat, CentOS, and Fedora
While this won't do any good for systems that are already installed, for those of you planning future installs, or new customers, you'll be happy to know that several common tasks have been automated and several common default configuration complaints have been corrected.[/i>
-----------------
I did get excited by my favourite word: "automated". I'm one of those odd people who actually do read announcements...... :-)
Anyway, thanks for the repairs, I'm going to try and get some serious time in on the Server next week and see what else I can come up with ...... :-)
I do hope to contribute some words - when I get a handle on things - to help other Newbies and I think a good entry-level FAQ would be a great start.
Have cut support enquiry by 84% on another project with a good prelim support FAQ.
Also - from experience elsewhere: it's hard to beat a Newsletter to prompt participation. I have been surprised at the low level of interaction on the Support Board here, but methinks now it might be because it mostly ain't so easy to support!
Cheers!
John
Ha Joe,
Well, got back onto job and found identical problem.
I can reinstall a new domain, but cannot do anything with it.
vis: Tried to upload new index.html and auxiliary files to Server:
1. t/fers look fine
2. Site not updated.
3. Can't delete the file insertion by skel default.
4. added a subdirectory both with and without index.html and nothing worked.
This is on http://netcapitalisation.com e.g.
I manually upgraded the etc/skel files and they didn't work either - despite deleting the existing domain's index.html.
I can't even tell where it is getting the data to display from, now. IF VMIN was ignoring my alterations, (adding index.html) then it should have displayed the brand-new-altered default one.
No alterations work.
I DO beleive it is a bug, now - but why hasn't it been multi-reported???
Anyway, I'll do it now.
Cheers,
John
Hey John,
<i>I DO beleive it is a bug, now - but why hasn't it been multi-reported???</i>
Because it isn't a bug.
You're putting your data in the wrong place.
If you login as the user in question, you'll start out in the correct home directory. Specifically, if you login as your user netcapitalisation.com (that's the username exactly...if you're logging in as anybody else, you're not logging in as the owner of this domain), it'll drop you right into:
/home/netcapitalisation.com
Within that is public_html. <i>That's where your content for netcapitalisation.com needs to go.</i> If you put it anywhere else, it isn't going to show up on netcapitalisation.com and it is not expected to.
So, if you want to upload a page to netcapitalisation.com, you first login (via FTP or FTP over SSH) as username netcapitalisation.com. Change directory to public_html. Upload you content.
Likewise, if you want to put content into fablor.com, you could login as the user "fablor.com". Same process.
You can do all of this as root, if you want to, but then you have to know where these guys home directories are, and you're also going to have to set the ownership of the files after your done uploading them.
Holler if this isn't clear.
BTW-The /etc/skel is only ever used when you first create the domain--it is <i>not</i> default data that comes up whenever content is not available. It gets copied into the new domain home directory when the user is created, and is never used again. Changing it after a domain has been created isn't going to have any effect on the domain's home directory or website.
--
Check out the forum guidelines!