Filed with Developers [Case 48382] skeleton directory for addon and sub domains

[Tam]

Getting very tired of the plethora of errors relating to favicon.ico, robots.txt and 404.shtml not being found in /usr/local/apache/logs/error_log, it leads to repetitive flooding of these errors and an un-necessary large log file, even with custom logging. Of-course it is easy for main domains with the skeleton directory facility but can this not be extended to addon and sub-domain additions?

[Infopro]

Getting very tired of the plethora of errors relating to favicon.ico, robots.txt and 404.shtml not being found in /usr/local/apache/logs/error_log, it leads to repetitive flooding of these errors and an un-necessary large log file, even with custom logging. Of-course it is easy for main domains with the skeleton directory facility but can this not be extended to addon and sub-domain additions?

It's easy with the cpanel3-skel directory to copy over these sorts of files (favicon, error pages, robots.txt, index.html, etc) on new account setup, I'm not sure how useful it is after the account is created.

If I understand, you'd like some default files pulled from the cpanel3-skel when a sub.domain or addon.domain is created by the cPanel user. But the user has no access to that cpanel3-skel directory of course, it's owned by root or reseller. Where would the files come from?

[Tam]

It's easy with the cpanel3-skel directory to copy over these sorts of files (favicon, error pages, robots.txt, index.html, etc) on new account setup, I'm not sure how useful it is after the account is created.

If I understand, you'd like some default files pulled from the cpanel3-skel when a sub.domain or addon.domain is created by the cPanel user. But the user has no access to that cpanel3-skel directory of course, it's owned by root or reseller. Where would the files come from?

I'd never assumed that they would be pulled from the existing skel directory.

This is rather pedantic.

Users under root or reseller do not have access to that skel directory either, do they.

[Infopro]

No. But the idea itself is still a good one I think.

[Tam]

Well, it would save a significant amount of logging, truly significant on a busy shared server anyway.

[sneader]

More discussion on this in this thread:

http://forums.cpanel.net/f145/skelet...ns-146569.html

(and several other older threads)

Basic concept is that when an Add-on Domain is created, there is nothing in the directory (no robots.txt or favicon.ico) which causes unnecessary Error 404's. And there are branding opportunities to have a basic "coming soon" page.

Look at it this way, why does cPanel offer the Skeleton structure for the main domain? The same reasons apply for the Add-on domain... so could you either copy the skeleton for Addon domains, too? Or offer us a separate directory for Addon skeleton files?

- Scott

[Infopro]

Why not post to that thread already created? That's the idea of the Feature Requests forum. The more posts the more important it can become.

[sneader]

Why not post to that thread already created? That's the idea of the Feature Requests forum. The more posts the more important it can become.

Sorry, I didn't realize the first one was in the Feature Request forum. I found it while searching for a solution and seeing no action in over a year, figured I would post it as a feature request.

Hopefully Don at cPanel will combine the posts or remove this thread and I'll post in the old one.

Sorry again (although it would have at least been nice of you to also acknowledge the effort, rather than yell at me for not following protocol )

- Scott

[Infopro]

Sorry, I didn't realize the first one was in the Feature Request forum. I found it while searching for a solution and seeing no action in over a year, figured I would post it as a feature request.

Hopefully Don at cPanel will combine the posts or remove this thread and I'll post in the old one.

Sorry again (although it would have at least been nice of you to also acknowledge the effort, rather than yell at me for not following protocol )

- Scott

I didn't yell and I could have merged them myself, as I just have, my intent was to ask you if there was something different about the two first, before touching anything, that I didn't see.

As for acknowledging this idea, I already have, in that other thread now merged together with this one. I like the idea.

That said, I think if I was to expand on my comments at all it would be this:

When I create a new account for a customer, and send them the details, they visit their domain and see my placeholder. The account is set to go.
But that customer may buy the account at 3AM, so not in the mood to work on the site right now, the placeholder serves a purpose.

When I create a sub.domain, I'm creating to use right now, and probably not at 3AM so the placeholder page / skel files may or may not be so important.

It would be nice to have the option asked for in this Feature Request though, yes, of course.

[sneader]

I didn't yell and I could have merged them myself, as I just have, my intent was to ask you if there was something different about the two first, before touching anything, that I didn't see.

OK, it's hard to know what people mean in text. Probably would have been better to say something like:

"Thanks for taking time to submit a feature request. Looks like the link you provided is already a feature request, so I will merge the two, unless you feel you need something different?"

Whatever, just letting you know I felt slighted for trying to help, even if you didn't mean to do that. Take it for what it's worth. In a community forum, I don't see the value in that.

When I create a new account for a customer, and send them the details, they visit their domain and see my placeholder. The account is set to go. But that customer may buy the account at 3AM, so not in the mood to work on the site right now, the placeholder serves a purpose.

When I create a sub.domain, I'm creating to use right now, and probably not at 3AM so the placeholder page / skel files may or may not be so important.

It would be nice to have the option asked for in this Feature Request though, yes, of course.

As for the 3AM stuff, I don't pretend to understand it. All I am asking for is to have skeleton files created for add-on domains, the same as for the main domain at account creation time.

Alternatively, if there is a "post add-on" script that I could hook into, I could just do it myself.

As it is, the users (and visitors) see a "Index of" page, plus the server gets 404s for the robots.txt and favicon.ico files, and it would be nice to solve those as well.

Thanks for listening.

- Scott

[cPanelDavidG]

So if I understand this thread correctly, the primary goal is to get rid of all these things causing entries in the error_log and the skeleton directory is just a proposed method for getting this done? I just want to make sure I understand what is important here before I generate a report.

[sneader]

So if I understand this thread correctly, the primary goal is to get rid of all these things causing entries in the error_log and the skeleton directory is just a proposed method for getting this done? I just want to make sure I understand what is important here before I generate a report.

May I answer the question with a question? Why does cPanel offer the concept of a skeleton directory in the first place?

Some things that come to mind:

1) Ability for the web host to brand the site, before the customer uploads content.
2) Ability to put a "coming soon" or "ready to go" page so the customer sees that the domain is properly configured and working on the server.
3) To avoid missing file errors on robots.txt and favicon.ico by automatically placing those into the customer's directory.

For the same reasons I might want the above things for the main domain, I would want them for addons too. Wouldn't you?

- Scott

[Tam]

Question is ... why have the skeleton directory in the first place? The answer would appear to be obvious and so it is there, so why would the answer for the same thing being there for addon domains not be so obvious?

In today's hosting environment, where we offer multiple if not unlimited addon domains to a single main domain account, the impetus to provide a such a useful thing uniformly should surely need little further encouragement?

[Tam]

sneader beat me to the rhetoric

[sneader]

sneader beat me to the rhetoric

Great minds think alike LOL