Frontpage & private_html
- Thread starter jw00dy
- Start date
yes, but I'm running into problems at this point. I have to go in and reset some files... I'll outline them and see if theirs a way to fix it or stop the changes from happening.
Some of these steps may not be needed, but this is what I did regardless of whether they are needed or not.
Also, please backup EVERY FILE BEFORE YOU EDIT IT!!! I will not be responsible for you using this hack (if you will) and jacking your system up.
Hope that helps.
I'd be interested to know what is editing the httpd.conf file and changing it from public_html back to private_html in the <VirtualHost [IP Address]:443> section (steps 13 & 14 above), and if theirs a way to stop this from happening, or a different way to implement what I'm attempting to do with this account. I've already had to change the info back one time (it's been working for 24 hours now). At this point I've just backed up this file and copy it over the original when it gets changed.
I'd love to hear if theirs a better way to do this. But FWIW, that's how I got it working.
Jonathan
Some of these steps may not be needed, but this is what I did regardless of whether they are needed or not.
Also, please backup EVERY FILE BEFORE YOU EDIT IT!!! I will not be responsible for you using this hack (if you will) and jacking your system up.
- First from the users directory (/home/<user>/domains/<usersdomainname.com>/) rename private_html to something else, e.g., # mv private_html private_html.bak
- create a symbolic link to public_html, e.g., # ln -s private_html public_html
- Go to /usr/local/frontpage, e.g., cd /usr/local/frontpage
- copy we80.cnf to we443.cnf (I got errors when this didn't exist, although I don't know why it's needed since we duplicate it later), e.g., # cp -p we80.cnf we443.cnf (this step may not be needed, although in my reading on the net it was advised to do it, and it doesn't exist otherwise).
- Go to DA's control panel and remove the FP extensions and then re-add them.
- This will create a www.usersdomainname.com:80.cnf (substitute the domain and tld for what yours are) file in /usr/local/frontpage.
- Take this file (www.usersdomainname.com:80.cnf) and edit it with your editor of choice, e.g., # vi www.usersdomainname.com:80.cnf
- Edit the line that says 'MailSender:' and append this after the : <localuseraccount>@usersdomainname.com, e.g. the line should look like this: MailSender:[email protected]
- Now find the 'SMTPHost:' field and make it the actual (this is what I did anyway and it's working) MX pointer, e.g., smtp.usersdomainname.com or whatever. So the line should read: SMTPHost:smtp.usersdomainname.com (usually in DA, this is mail.usersdomainname.com, but I like them to be smtp, so I change them all, and just cname mail to smtp
, BTW, is their a file I can change that will automatically do this instead of mail.domain.com?)
- Save and exit the file
- Now take and copy this file so you have an https (443) version, e.g., cp -p
www.usersdomainname.com:80.cnf
www.usersdomainname.com:443.cnf
- Now this is where I think my problems (re-occurring) are coming from, although I know of no other way to make this work without changing this file. Go to /usr/local/directadmin/data/users/<localuserid>/ , e.g., cd /usr/local/directadmin/data/users/user1/
- Edit the httpd.conf for the user, e.g., vi httpd.conf
- Find all instances of 'private_html' and replace them with 'public_html'
- If you don't do this, you WILL get a password prompt when trying to run the secure frontpage forms.
- I also added "Port 443" (without quotes) at the top of this file. Not sure you need it, but I added it anyway... It seems to allow you to publish using https, though I'm not sure since quite frankly I don't use FP and don't care for it (major headache for me, unfortunately, my users don't agree
)
- Save and exit.
- Now restart httpd and you should be good to go, e.g., # service httpd restart
Hope that helps.
I'd be interested to know what is editing the httpd.conf file and changing it from public_html back to private_html in the <VirtualHost [IP Address]:443> section (steps 13 & 14 above), and if theirs a way to stop this from happening, or a different way to implement what I'm attempting to do with this account. I've already had to change the info back one time (it's been working for 24 hours now). At this point I've just backed up this file and copy it over the original when it gets changed.
I'd love to hear if theirs a better way to do this. But FWIW, that's how I got it working.
Jonathan
Last edited:
When you say:
"until the httpd.conf gets changed again"
what process is precisely changing the httpd.conf
An action must be invoked for the httpd.conf to be changed.
Also I am assuming you are speaking of the user's httpd.conf and not the main httpd.conf. I sthis correct?
"until the httpd.conf gets changed again"
what process is precisely changing the httpd.conf
An action must be invoked for the httpd.conf to be changed.
Also I am assuming you are speaking of the user's httpd.conf and not the main httpd.conf. I sthis correct?
Yes the users httpd.conf.
As far as the process??? I have no clue. I changed it yesterday and got it all working. Then in the afternoon my customer called and said they were getting a password prompt when they tried to submit secure FP forms.
So I knew immediately that the paths in the 443 section of the users httpd.conf file were not correct, and sure enough they weren't. However some of them still were, just not all???
Anyway, I have no idea who or what changed them, but they worked for them all morning and then in the afternoon they stopped working again.
I was asleep at the time (I work graves for my normal job), so I know it wasn't me but what ... 
Hope that helps.
As far as the process??? I have no clue. I changed it yesterday and got it all working. Then in the afternoon my customer called and said they were getting a password prompt when they tried to submit secure FP forms.
So I knew immediately that the paths in the 443 section of the users httpd.conf file were not correct, and sure enough they weren't. However some of them still were, just not all???
Anyway, I have no idea who or what changed them, but they worked for them all morning and then in the afternoon they stopped working again.
I was asleep at the time (I work graves for my normal job), so I know it wasn't me
but what ... Hope that helps.
Actually it's possible I may have changed some of this users info from DA (DNS I think and maybe increased their storage and bandwidth, though I don't remember for sure). So that's possible. However, I did all that in the middle of the night (around 3-4 AM), then at 7 AM I talked to them, we did some testing, and it all worked at that point.. then I went to bed.
I could test it over the weekend while they aren't getting hit with customers and see if it "breaks" my hack again by changing some of their stuff in DA.
Let me know if you figure anything out and I'll see if I can figure out what I may have done that would remove the changes I made. I'm thinking, any change from DA related to Apache might trigger the changes, but I don't know for sure.
Thanks again. I love a fox hunt, just not when my customer is breathing down my kneck...
I could test it over the weekend while they aren't getting hit with customers and see if it "breaks" my hack again by changing some of their stuff in DA.
Let me know if you figure anything out and I'll see if I can figure out what I may have done that would remove the changes I made. I'm thinking, any change from DA related to Apache might trigger the changes, but I don't know for sure.
Thanks again. I love a fox hunt, just not when my customer is breathing down my kneck...
That is very strange. What could possibly be running that would changed the user httpd.conf for no apparent reason. It's not like we are talking about Cpanel Maybe you should email [email protected] and ask them what process could be changing your conf.
Maybe you should email [email protected] and ask them what process could be changing your conf.