Find content
Not Telling
Display name history
Hey Folks,
You guys successfully setup SSL for the various Hsphere services on my cloud, but there are a couple of instances where the CP defaults to non-https access, and I was wondering if we can find a work-around for this.
Specifically, even if you enter the CP via https, the WebShell link takes you to the non-https version, as does the Webmail, phpMyAdmin links, etc. Now, I know where the files are located for these services/scripts, so what I was wondering is if you drop an .htaccess file in that folder to redirect http to https, if that'll work. I know you can't edit the files without them being overwritten on updates, but since an .htaccess file doesn't exist by default, will it be overwritten or skipped? Could it be chattr to immutable?
If that's not possible, can I make a skin -- basically just take the existing skin and change those few links to make them all https?
What I'm trying to do is find a way to force ssl for these services, since the average user is NOT going to manually change the URL after clicking a link in the CP to access Webmail, WebShell or phpMyAdmin.
Thanks,
Steve
Topics I've Started
Cloud CDP practices
22 September 2010 - 10:24 AM
I was on my cloud's cdp account the other day, and noticed that each of the 15 daily "snapshots" was exactly 24 hours apart. This led me to wonder if on a cloud server, the r1soft agent isn't setup for continuous (or near) protection, but just takes a daily snapshot. IOW, mine seems to be taken at 8:30 in the morning, so if I put up a new set of files at 9:00, are those exposed and vulnerable until the next snapshot the following day?
Basically, I'm just not clear on exactly how "continuous" the Continuous Data Protection is for the cloud servers.
And is this configurable?
Thanks!
Steve
Basically, I'm just not clear on exactly how "continuous" the Continuous Data Protection is for the cloud servers.
And is this configurable?Thanks!
Steve
Exim and usernames
25 June 2010 - 09:26 AM
Who's the exim expert around here? I've been setting up dkim on my cloud instance (working great, btw), but in the process of studying all those email headers, I also noticed that the return-path is being set to the actual username@host.name.com. That feels a little insecure to me, since it reveals the host server, and the user's login name.
Is there a setting in exim.conf that can force this to the user's domain (ie, user@userdomain.com) or the email sender address? I know this can be set in individual php scripts with the -f flag, but is there somewhere *I* can set it to force it always on?
What's the best practice here?
Thanks
Steve
I've been setting up dkim on my cloud instance (working great, btw), but in the process of studying all those email headers, I also noticed that the return-path is being set to the actual username@host.name.com. That feels a little insecure to me, since it reveals the host server, and the user's login name.Is there a setting in exim.conf that can force this to the user's domain (ie, user@userdomain.com) or the email sender address? I know this can be set in individual php scripts with the -f flag, but is there somewhere *I* can set it to force it always on?
What's the best practice here?
Thanks
Steve
Perms to prevent .htaccess alterations
01 June 2010 - 11:10 AM
What is the best set of perms to prevent scripts from tinkering with an .htaccess file (including the control panel, DA in this case)? I had installed a forum script in a private subdomain, protected with .htaccess. When I found the forum software unacceptable, I deleted the files via the DA control panel before installing a different script, which (of course) deleted the .htaccess file, and the private subdomain was no longer so private. Luckily I discovered the problem quickly, but it brought this question to mind.
Since this is a cloud server, and I have SSH access, I can change the perms and owner:group to whatever will work best. Mostly, I don't want any php script to be able to alter the file, nor be able to delete it from the DA control panel. I know if it's set to root:root, DA can't delete it, but I don't think it'll actually WORK with that owner:group. So, what's the best way to handle this?
FWIW, I would normally just put the auth code in the httpd conf vhost section, which is off-limit for scripts, but then the DA password function won't work (or is that wrong?).
Anyway, thoughts?
Thanks!
Steve
P.S. Goodness... looks like I'm monopolizing this forum
monopoly.png 83.34K
5 downloads
Since this is a cloud server, and I have SSH access, I can change the perms and owner:group to whatever will work best. Mostly, I don't want any php script to be able to alter the file, nor be able to delete it from the DA control panel. I know if it's set to root:root, DA can't delete it, but I don't think it'll actually WORK with that owner:group. So, what's the best way to handle this?
FWIW, I would normally just put the auth code in the httpd conf vhost section, which is off-limit for scripts, but then the DA password function won't work (or is that wrong?).
Anyway, thoughts?
Thanks!
Steve
P.S. Goodness... looks like I'm monopolizing this forum
monopoly.png 83.34K
5 downloads
