Posts by viper_iii

    Install fine -
    only issue was "Challenges failed for all domains"


    I am not using DNS from imscp - instead using Cloudflare/domain registratr - this case I think is Godaddy actually (which i don't prefer) - which hasn't been an issue in the past that I know of.
    external mail server is the only tricky part but not major and is fairly easy to deal with.


    letsencrypt log file
    /var/log/letsencrypt/letsencrypt.log


    Probably simply be an .htaccess issue on wordpress causing the problem.


    this is default wordpress .htaccess


    Code
    1. # BEGIN WordPress<IfModule mod_rewrite.c>RewriteEngine OnRewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule># END WordPress


    letsencrypt log file
    /var/log/letsencrypt/letsencrypt.log
    does show the failures
    dns - expected -
    http-01 not expected - but think it was the .htaccess.




    --- Update ----


    I updated the wordpress .htaccess and have been given a cert which works
    but I also want to force https without HSTS due to that really getting the cache fouled up if I change DNS over to Cloudflare


    Modified 1st .htaccess


    Code
    1. RewriteRule "(^|/)." - [F]the following rule:RewriteRule "^.well-known/acme-challenge" - [L]# BEGIN WordPress<IfModule mod_rewrite.c>RewriteEngine OnRewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule># END WordPress


    What is the best way now to force HTTPS?
    tried:


    adding lines 10 & 11... that pissed off the wordpress install pretty good...




    Just wanted to say thanks


    Last Quite a few upgrades for me have been smooth without any issues, much appreciate all the work that goes into all the bug fixing that is being done.


    Sure a few bugs - but last year upgrades occasionally broke during the upgrade (typically due to my config problems - not i-mscp)


    Anyway thanks again. :D


    --- small update ---
    older server was a bit behind - on wheezy and php 5.5 manually setup few years ago...


    the installer passwords like example: eD%r$EZaw=dKG9V8 > threw an error and had to remove any non letter numbers else it threw a fit about non-allowed characters.


    so for example: eDrEZawdKG9V8 (was allowed)

    Wheezy 7.11


    php 5.5 manually installed


    upgraded 1.3.5 > 1.3.7
    before upgraded manually edited docs/Debian/packages-wheezy.xml
    and removed the line:
    <package post_install_task="php5dismod apc && php5enmod apc">php-apc</package>
    which will cause the installer errors per old errata.
    ---
    install proceeds and shows success -
    nginx errors out for panel...
    all sites work fine


    502 bad gateway
    nginx


    errors in log show:
    Old Wheezy: 2016/10/26 10:04:27 [crit] 11772#11772: *17 connect() to unix:/var/run/imscp_panel.sock failed (2: No such file or directory) while connecting to upstream, client: 10.25.1.10, server: paneldomain.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/imscp_panel.sock:", host: "xxx.xxx.xxx.xxx:8443"



    Upgraded my Jessie 8.6 Server without any issues -
    which is the server I'd like to move everything over to and relieve this older wheezy server and remove it.


    not many sites so it might be time to just move them manually.


    Migrate i-mscp domains to a new server
    that post is part of that question - what would be the best way to migrate over to the jessie server (in another enviorment)

    Sorry I don't follow the script..


    it looks like from a very laymen review that it backs up the old server and then restores on a new one?


    my new server is in a new datacenter and really only need to move a few gigs total, but servers are not physically near each other..
    do / can have ssh (scp) though.


    I my situation - much like his above - I want to only move a few sites....
    however i don't have any email only sites with mysql on them - either way still have several sites I'd like to move without having to manually ssh them over then the database as well. and then chmod all back into proper permissions....


    however I can / will if that is the only option.

    lost on which flag to clear -
    when HSTS is enabled
    several sites were still getting 301 Redirect error


    I've removed the HSTS and sites are working again and forcing https via other methods.
    not sure what changed to cause the issue or what exactly to clear
    the upgrade to 1.3.5 didn't clear / reset the flags.

    checked:


    /etc/apache2/sites-available/dwtsolutionsllc.com.conf
    see the 301 redirect in place seems correct..


    <LocationMatch "^/(?!.well-known/)">
    Redirect 301 / https://dwtsolutionsllc.com/
    </LocationMatch>


    checked:
    /etc/apache2/sites-available/dwtsolutionsllc.com_ssl.conf


    Header always set Strict-Transport-Security "max-age=31536000"


    is that the flag to clear manually?


    also verified chrome clearing cache and hsts (manual deletion of domain) no change.
    https://really-simple-ssl.com/…-base/clear-hsts-browser/



    is there somewhere else I should be looking?


    attempted to remove line
    Header always set Strict-Transport-Security "max-age=31536000"


    and set to NO for HSTS strict in panel


    still not loading.


    Checking for redirect in:
    /etc/apache2/sites-available/dwtsolutionsllc.com.conf
    this line no longer exists after change in panel.


    <LocationMatch "^/(?!.well-known/)">
    Redirect 301 / https://dwtsolutionsllc.com/
    </LocationMatch>


    service apache2 restart
    or
    /etc/init.d/apache2 force-reload


    now working again only for domains that I manually set NO Strict HSTS.
    ---
    re-enabling hsts and service apache2 restart
    - goes directly back to Error Page.


    seems the redirect isn't working properly???? - hopefully Cloudflare isn't the Root of it!!
    /etc/apache2/sites-available/dwtsolutionsllc.com.conf


    <LocationMatch "^/(?!.well-known/)">
    Redirect 301 / https://dwtsolutionsllc.com/
    </LocationMatch>

    updated to 1.3.5 - smoothly no issues


    in my case still remove apc from packages as I have php5.5 for the base.


    also followed errata and stopped services and umount remount procedures noted in errata.
    because I was upgrading from a version higher than 1.3.2 - at least that was how I read it... (could be wrong and wasn't needed)


    still
    http://dwtsolutionsllc.com
    and others still giving same error.
    going into manual fix.


    if it was browser HSTS issue the browser error would be different.
    like: ssl_error_bad_cert_domain / cannot connect to the real <domain>


    rebooted server - and planning to check manual settings shortly per above recommendation.

    Since updating to 1.3.3


    have had a few issues with https only sites -
    setting on the domain is set to force https (I think)
    Wheezy Debian (7)
    fastcgi I think - not 100% sure
    showing FPM - verified via phpinfo
    (fpm manages memory better? thought 1.3.x forced it over? - I might have to get re-introduced to verify that)
    using panel redirect - plugin and phpswitcher
    USING CloudFlare - so very possible that is causing the issue as well.
    but it seems to be passing traffic fine.


    var/log/apache2/<domain>
    [error] [client 173.245.48.240] client denied by server configuration: /var/www/
    IP is cloudflare


    http://oceanodunes.org
    getting a 403 - 301 permanently moved -


    http://dwtsolutionsllc.com/
    http://amps-corp.com
    manually change to https - they work fine.
    then it no longer will show the error page it forces over to https and works every time (browser cache?)
    however I don't know if visitors are redirected on initial load.


    even changed them to not force https and loads normal http.
    re-enable https

    HSTS (HTTP Strict Transport Security)


    and some start working - amps-corp.com - goes back to 403-301 error.


    Don't believe it was happening previously, but honestly couldn't say for sure.

    1.3.3 went smoothly.


    No issues.


    plugins - disabled all but panel redirect - left that one and upgraded.


    then upgraded - checking errata - currently have OS updated to 5.5 still have to remove wheezy line for APC in doc/Debian/packages-wheezy


    install no issues


    updated plugins - all current from panel redirect / server default page / lets encrypt / phpswitcher
    all working correctly.


    - issue with databases remains.. noticed in 1.3.0 - haven't checked if there is an issue I don't know know about..


    found in 1.3.0 - didn't report expected it might be reported / fixed / my install has/had an issue.


    • create new DB - add existing DB user
    • only shows [email protected] instead of listing user in drop down.

    have to select user and change based on alpha listing (i think) if you have multiple but not sure.


    image attached.


    beyond that issue - all is running correctly...

    Files