An issue with IP/~users bandwidth

Feature request

I didn't realize there was a special token, so I used the following line in /usr/local/directadmin/data/templates/custom/virtual_host.conf file:

ServerAlias www.|DOMAIN| |DOMAIN| |USER|.main.domain
Click to expand...

where main.domain - is the main domain of the server.
By main domain I mean the domain belonging to admin account.

Main domain has a secure certificate, which is shared by all users.
The question now is how to use the shared certificate w/o user directory.
If the domains would have the ROOT directory that looks like
/home/DOMAINNAME/public_html, I could use an internal redirect to access DOMAINNAME as https://main.domain/users/DOMAINNAME/ , but I am not sure how to do that with the path structure we have right now.
I was wondering if it would be possible to make a special directory (for example, /etc/httpd/sites) where will be symb links to root directories of domains, like this
domain1.com => /home/USER1/domains/domain1.com
domain2.com => /home/USER1/domains/domain2.com
domain3.com => /home/USER2/domains/domain3.com
 
Got this bug:

LogFormat takes 1-2 arguments, a log format string (see docs) and an optional format name

LogFormat "%b "%r"" homedir

Do I have to modify homedir or?
 
Thank you, that's a nice feature indeed, but all domains except default one remain inaccessible until propagated. Also, security-wise, I would be happier using full domain names than a username.

I could write a script (to be called from CRON, say, every 5mins)that would go thru all directories in /home and create symb. links as described above, but this looks like unnecassary overhead on the servers with 200+ users.
 
Hello,

all domains except default one remain inaccessible until propagated
Click to expand...
As it has always been. You can change the main domain for the account by going to User Panel -> Domain Administration -> select the new domain and click "Set as Default".

LogFormat takes 1-2 arguments, a log format string (see docs) and an optional format name
Click to expand...
Yes... I see two. When you put the text between quotes, it becomes 1 argument as 1 string. Just add it as seen in the example.

would be happier using full domain names than a username
Click to expand...
One other option, actually quite a simple change, would be to add:

ServerAlias www.|DOMAIN| |DOMAIN|.serverhostname.com

to the virtual_host.conf templates (similar to the method used a few posts up) which would give you access to all domains before propogation.

John
 
DirectAdmin Support said:
Hello,

all domains except default one remain inaccessible until propagated
Click to expand...
As it has always been.
Click to expand...

That's why I put "feature request" subject in my post ;)


One other option, actually quite a simple change, would be to add:

ServerAlias www.|DOMAIN| |DOMAIN|.serverhostname.com

to the virtual_host.conf templates (similar to the method used a few posts up) which would give you access to all domains before propogation.
Click to expand...

This works fine for non-secure URLs, but how one can access the site securely with the server shared certificate?
 
Last edited:
This works fine for non-secure URLs, but how one can access the site securely with the server shared certificate?
Click to expand...
Put it in the virtual_host_secure.conf too. :) Sure they'll get a popup, but it's still secure. If you're using ssl, it's going to be secure regardless if the certificate is verified or not.

John
 
Nah, I can't do that. We are hosting mostly e-commerce sites, if they see a popup called 'Security Alert' they will get cold feet regardless if the connection is secure or not :)
 
Webcart said:
Nah, I can't do that. We are hosting mostly e-commerce sites, if they see a popup called 'Security Alert' they will get cold feet regardless if the connection is secure or not :)
Click to expand...

Then you should concider a wild-card ssl certificate, that will allow any subdomain to have ssl without the pop up. It costs quite a bit more, but if you really need the feature, then that would be your only other option.
 
The primary purpose of a cert is to identify the site.

So there's no way to use a cert for one domain to secure another domain without a popup.

Sure you can buy a wildcard cert, for something such as *.example.com, so all subdomains of example.com will work securely without the popup, but I don't think you're going to get anyone to issue you a cert for *.com. or for *., and if they did that would make the whole Internet totally insecure.

Jeff
 
jlasman said:
The primary purpose of a cert is to identify the site.

Jeff
Click to expand...

With all the respect, I don't think this is an accurate statement. For one, some secure certificates can be issued within minutes and do not require much authentification to be issued. For two, we only need a certificate to provide encrypted connection and we would happily use self signed certificates if they wouldn't trigger a pop up window, which is rather confusing for most non-techie users.

Right now, we offer secure links in the form https://serverhostname.com/~username for all our clients, but like I mentioned before, this only provides an access to 1 domain per user. This might be not a big deal for someone else, but for us it's a very serious limitation.
 
toml said:
Then you should concider a wild-card ssl certificate, that will allow any subdomain to have ssl without the pop up. It costs quite a bit more, but if you really need the feature, then that would be your only other option.
Click to expand...

This is a good idea and we will probably use it for subdomains, but like jlasman said it will not work in for the case described above.

As far as I know, there are only 2 ways to access one domain thru another:
1. UserDir (i.e., https://onedomain.com/~username)
2. Redirect via AliasMatch or RewriteRule

The first one has a limitation of making only 1 domain available and the second one needs ROOT directories of domains in the form
/home/DOMAINNAME/public_html
 
DirectAdmin Support said:
Yes... I see two. When you put the text between quotes, it becomes 1 argument as 1 string. Just add it as seen in the example.
Click to expand...

I still get an error after manually adding

LogFormat "%b "%r"" homedir

to httpd.conf

Missing something.?

Jon
 
I put this and it fixed the error. I'm not sure if it messes up the stats or not, but it got apache to start.

Code: 
LogFormat "%b \"%r"\"" homedir
 
Last edited:
jmstacey said:
I put this and it fixed the error. I'm not sure if it messes up the stats or not, but it got apache to start.

Code: 
LogFormat "%b \"%r"\" homedir
Click to expand...

Are you referring to webalizer? Does it mess the stats up?

John - is this the correct format?

regards

Jon
 
jmstacey said:
I put this and it fixed the error. I'm not sure if it messes up the stats or not, but it got apache to start.

Code: 
LogFormat "%b \"%r"\" homedir
Click to expand...

I tried your method and it didn;t work so looked at the LogFormat in the httpd.conf that exists already:

LogFormat "%h %l %u %t \"%r\" %>s %b" common

Changed mine to

LogFormat "%b \"%r\"" homedir

regards

Jon
 
Hello,

You can have multiple LogFormats. If you've removed the "common" log format, you'll probably want to add it back :)

John
 
Webcart said:
With all the respect, I don't think this is an accurate statement.
Click to expand...
From my point of view, I agree with you. Today most of us think of a cert as only a method to secure data, and not to identify the site.

However it doesn't what you and I think. What matters is what cert's were invented for, and why they exist.

Here's a good example of what a cert is for.

And Thawte says the same.
For one, some secure certificates can be issued within minutes and do not require much authentification to be issued. For two, we only need a certificate to provide encrypted connection and we would happily use self signed certificates if they wouldn't trigger a pop up window, which is rather confusing for most non-techie users.
Click to expand...
Even the low-priced guys (such as InstantSSL, which we resell) believe in identity verification, as it really is the primary reason certificates were originally invented. We had to agree to verify all our customers before Comodo (InstantSSL) would let us approve certificates for our customers.
Right now, we offer secure links in the form https://serverhostname.com/~username for all our clients, but like I mentioned before, this only provides an access to 1 domain per user. This might be not a big deal for someone else, but for us it's a very serious limitation.
Click to expand...
The limitations in certificates are designed into them to make it hard for people to pretend to be someone else; even the cheapest certs offer a $50 indemnity if their cert allows you to log into a website owned by someone other than whom they say it is.

The limitations in Apache, however, are easier to get around :) .

It's amazing what you can do with links. So perhaps that's what you need to look at.

Then you can set up your own structure, and allow multiple directories inside users; something such as this:

https://serverhostname.com/~username/domain

Jeff
 
jlasman said:

From my point of view, I agree with you. Today most of us think of a cert as only a method to secure data, and not to identify the site.

However it doesn't what you and I think. What matters is what cert's were invented for, and why they exist.
Click to expand...
I recognize good intentions behind this idea, but what really matters in commercial environment is how an idea can be put to work and the bottom line is that most people don't have a slight idea about certificates, but they get anxious when a window titled "Security alert" suddenly pops up.
And our clients running e-commerce sites are in line with that trend: so far, we have only 1 cert. installed on the server with 100+ domains (beside our shared cert, that is). People just don't like to pay for it and I can't say I blame them :)
It's amazing what you can do with links. So perhaps that's what you need to look at.

Then you can set up your own structure, and allow multiple directories inside users; something such as this:

https://serverhostname.com/~username/domain
Click to expand...
Thanks, I thought about that a lot, I hate to beg for new features and prefer to do-it-yourself style when possible, but this little experiment turned out to be impractical: it's still too confusing for non-techie users for one, and it doesn't allow to make transparent move of sites to another server for two.

I will go with a script that maintains symb links to root directories for all domains, even though I have to call it from cron.
 
Webcart said:
I recognize good intentions behind this idea, but what really matters in commercial environment is how an idea can be put to work and the bottom line is that most people don't have a slight idea about certificates, but they get anxious when a window titled "Security alert" suddenly pops up.
Click to expand...
I agree with you here as well. But the cert issuers would never agree with you, and if they did, then the browser companies wouldn't allow their certs to be authoritative. And if they did athe entire Internet community would probably be up in arms over it.

Certainly the low-priced companies who need "chain" or "root" certs have agreements in place with their chain/root cert suppliers that they're not allowed to do it with those chain/root certs.

Which is why we'll never see wildcard certs offered from cert vendors for the root "." domain or even a second-level domain such as .com.

So as I said, it doesn't matter what you or I think or would like to see.
[/quote]And our clients running e-commerce sites are in line with that trend: so far, we have only 1 cert. installed on the server with 100+ domains (beside our shared cert, that is). People just don't like to pay for it and I can't say I blame them :)[/quote]
They may not know they can get inexpensive certs. Certainly there's a price to be paid for security, whether it's locks/gates/alarms in a brick-and-mortar store, or a cert for an Internet-based store. We've never had a client flinch at the idea of a $50/year cert (we resell Comodo certs for a bit less than Comodo sells them for), and in fact, though we offer a shared cert, we're the only ones using it.

Our shared cert is for the "https://secure.ezsecureusa.com/" domain; click on it to see what you get.

To see it in work, try:

"https://secure.ezsecureusa.com/nobaloney/domains/"

In this case, secure.ezsecureusa.com is the site we bought the cert for, and nobaloney is the subdirectory we set up for the nobaloney.net domain. domains is a subdirectory set up in the nobaloney.net domain by the nobaloney.net webmaster for selling domains.

Because the folk who browse don't know to look for "https://secure.ezsecureusa.com/nobaloney/domains", we created a domain at "domains.nobaloney.net" and created a site redirection from the root directory to the secure.ezsecureusa.com directory.

We do all this ourselves for the users who require it (though as I mentioned above, so far no one uses it but us), and we create links so the user still loads and uploads to his private_html directory.

Jeff
 
You must log in or register to reply here.
Back
Top