Jessie

From another thread:- GRBoomer 2 Mar '17 I accidently deleted my nextcloud user and admin accounts from the database. I still have the same database. I recreated new admin and user and got nextcloud up and running and pointed back to my data. However, I cannot login into the Passman vault. I did save a copy of the original config.php file and the entire original directory. Moving salt values and origins over to the new config file prevents me from getting into nextcloud, and having the new values prevents me from getting into Passman. Is there a way for me to recover my vault? I do have the password correct too. Also, selecting recover password tends to only give the option to the admin (me) of deleting the vault. There is not password recovery unless the words mean something else. [SOLUTION] I copied the passwordsalt and secret into config.php (I had already done that) I think restarting the webserver (Apache) is the difference that made it work. Other than that, I've found that periodically backing up the calendar app from within the calendar also backs up tasks and others. Not sure whether passman is included in this. This method as far as I know is the only way to recover the calendar.

Are you aware that if you log in as administrator you can click on the user icon on the top right hand side of screen and select apps from there?

Not sure if this is relevant to you, but in Australia some services have the VOIP phone service locked into the modem/router. This becomes an issue if the modem/router won't do what you want. A work around here is we use the modem of our choice which gives us the functionality we need and then we run the carrier supplied modem off one of the ports in the replacement modem. The carriers modem will provide phone functionality only and the replacement modem does the rest. The carrier modem needs to be operating in a different subnet to the replacement.

yep. Did it via nextcloud settings. It crashed during step 4, but it is only a timeout. Give it time to complete, then exit out and select update again and it will pick up where it left off. Probably wouldn't hurt to backup before you start.

If you go to the nextcloud directory in your array, there should be subfolders for each of your users. The files will be in there. There are ways to rebuild. Another more tedious way is to recover the files from these directories. Recreate nextcloud and resync them.

So are you still having issues? I recall the same symptoms but only when using ie in win10. As ie seems to be pretty well past its use by date, not a big issue. I don't use chrome, but the problem was not there when using firefox or edge. letsencrypt shut down correctly.

Are you using Internet explorer? Try Edge or firefox.

More on this. (Todo with slow nextcloud logins.) One solution was to use a pfsense router. Pure horsepower overcame the slow login. If using a normal router I found enabling Bruteforce app, then going to settings and whitelisting the ip address of the router fixes it. It seems that even if bruteforce is disabled, it still works in the background. This method solved "No connection" errors on the client apps also.

Well it looks like I finally worked out what was going on with this slow nextcloud issue. Looks like it was the router. Swapped the system out with a pfsense router. Result pretty well instantaneous login. Nothing under 25 to 30 secs after pressing the login button on the old router. Just in case anyone was wondering. A few months down the track and nextcloud was slow again, even through the pfsense firewall. unraid "Docker safe new perms" fixed it. (Requires the "Fix common problems" plugin)

Database is on SSD Cache. The Storage drive on the Array is set to never spin down.

Well it looks like it's not nextcloud. I replicated a second server on my own system using 13.04 and it is fast. I loaded v13.0.0 onto the new machine and it is still slow. Might have to look at the database engine and the interconnect. Any tips?

You learn something new everyday. Thanks for that.

CHBMB, is there a way I can get a previous container eg nextcloud v13.00 for testing purposes. I would like to load it into this new system I am having issues with to try and determine whether the slow response is due to nextcloud 13.0.4 or something else.

Nothing obvious. I did find a message relating to speed in version 11. The author toggled the brute force app on then off. So I did the experiment. I toggled it on then back off, loging on in between toggles. It now logs on in around 40 seconds and takes 20 seconds to log out. Not sure whether it is a coincidence but that is faster. Still unacceptably slow though. More tests later. I don't think toggling brute force has any relevance. Still slow. I did the test on my working system. About 1 second to log on and almost instantaneous to log off.

Have you tested the current container install on a new system using CA? Was the system slow? Out of the box, I am getting 25 second delays to the log on screen, then more than a minute to log into nextcloud. (My existing system using 13.02 logs on in seconds)

I don't but I suspect CPU may be a factor and RAM as I noticed a much quicker response time after I upgraded my server. 1/ Are you running the latest versions CHBNB? 2/ Did you install them via community apps? 3/ Maria or MYSQL?

If you run it straight out of the box it installs SQLite. Which works, but falls apart if you hammer it. It does work when it works, with MYSQL or Maria. But it always seems a lottery. You don't know whether it will be fast or not. In my experience, computer horse power doesn't seem to be a factor. I have systems running on old generation i5 processors which respond better than others on current generation xeons. Historically for me, the slow issue started half way through NC version 11. Version 12 was unusable for me, then 13.0 fixed everything. Now I'm not sure what is going on. My main system is on 13.02 and MYSQL on an unraid in dockers. Letsencrypt docker does the reverse proxy and certificate bit and it works well. I'm not game to upgrade to 13.04 at this stage in case 13.04 kills it.

Question 2 Is there a procedure to get version 13.02 as a docker rather than 13.04 on a new install? If so how do you do it?

Has any one noticed a slow down in performance from say 13.02 to 13.04. I have a machine running 13.02 which will log in in 2 seconds. 13.04 takes 25 seconds. Have tried 13.04 on a couple of computers. Same result. Slow. Don't know why. Yes I have checked the "Brute force" datafile and emptied it or it was already empty. Am using MYSQL docker and letsencrypt docker.

I'd prefer not to use self signed certificates but they work if SBS is the only system being fed through port 443. The problem is I also run nextcloud and letsencrypt docker which provides the certificates for nextcloud. Because letsencrypt must have 443 and SBS also must have 443, they need to go through the reverse proxy. Letsencrypt used to provide certificates for sbs but that fell apart when they banned TLS type certificates. The main purpose of SBS is to provide an exchange mail server. File server functions can easily be handled by Unraid. SBS is also a domain controller presently. In the future, I will look at Samba as a domain controller. I plan to retire SBS in 2020 when they drop support. Still looking for a viable replacement for exchange. I am now running a pfsense router as a vm on unraid. If I can't get SBS to go using current methods, I am looking at the possibility of generating letsencrypt certs and reverse proxying through pfsense. Spare time is my enemy here. I also can't afford much downtime for my system either.

How can I reverse proxy my Small business server through the letsencrypt docker without adding the letsencrypt certificates. ie I want to be able to connect to https://remote.mydomain.com.au I want this to pass straight through the letsencrypt dockers reverse proxy to the sbs server. The SBS server will provide self signed certs rather than letsencrypt certs. The config file is shown below. I have hashed out what I think would be needed to pass straight in and out again. It doesn't work of course, which is why I am posting here. server { listen 443 ssl; server_name remote.mydomain.com.au; # root /config/www; # index index.html index.htm index.php; ###SSL Certificates # ssl_certificate /config/keys/letsencrypt/fullchain.pem; # ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ###Diffie–Hellman key exchange ### # ssl_dhparam /config/nginx/dhparams.pem; ###SSL Ciphers # ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ###Extra Settings### # ssl_prefer_server_ciphers on; # ssl_session_cache shared:SSL:10m; ### Add HTTP Strict Transport Security ### # add_header Strict-Transport-Security "max-age=63072000; includeSubdomains"; # add_header Front-End-Https on; # client_max_body_size 0; # proxy_request_buffering off; # proxy_buffering off; location / { proxy_pass https://192.168.10.27:443/; proxy_max_temp_file_size 2048m; include /config/nginx/proxy.conf; } }

Keen to try this out. Any documentation out there? By the looks I would have to create a number of subdomains, letsencrypt certs etc. A youtube tutorial would be nice.

Thanks. I'll have a look.

I never resolved my issue with the letsencrypt docker and sbs server. ie it stopped after they banned tls-sni. What I haven't tried yet is the dns approach to authentication. I read somewhere today that this approach might be as simple as placing a txt record in DNS. Could it be that simple? If so, how do I derive/configure the txt string that would work? My other option would be to try to configure letsencrypt via pfsense. Not sure how that would go.

In SBS server, if you try to go to http://remote.mydomain.com.au, the server will detect the address and rename the url to https://remote.mydomain.com.au. So the only function of port 80 in sbs is to redirect HTTP:// to HTTPS:// on port 443. So when it worked, sbs might see the http:// on port 80, but then it redirected to HTTPS:// on port 443 which went via the reverse proxy. If you try to go directly to https://remote.mydomain.com.au, port 80 is not involved in the process. There was another issue with the original configuration. Emails to external devices would time out. A bit of googling discovered that if you inserted the following lines just before the redirect, all would be good. proxy_request_buffering off; proxy_buffering off; I still have 2 servers running this configuration. They will work until the certificates expire then they will stop. When the changes to LE happened and I had to forward port 80 to internal port 8088 on the Unraid Server, the path through the proxy to SBS stopped at the same time. I incorrectly thought that port 80 was the cause. The loss of port 80 only means that I must use HTTPS://remote.mydomain.com.au. That's not really an issue from a user perspective. I spent last weekend trying to solve this. Whilst I now have a better understanding of how this thing works, I am no closer to an answer. Below is a typical entry from the nginx log when it fails. 2017/12/24 22:22:31 [error] 357#357: *303 upstream timed out (110: Operation timed out) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: remote.mydomain.com.au, request: "POST /Microsoft-Server-ActiveSync?Cmd=Ping&User=we.local%5Crach&DeviceId=SEC18D91DF70EF08&DeviceType=SAMSUNGSMG930F HTTP/1.1", upstream: "https://192.xxx.xxx.xxx:443/Microsoft-Server-ActiveSync?Cmd=Ping&User=we.local%5Crach&DeviceId=SEC18D91DF70EF08&DeviceType=SAMSUNGSMG930F", host: "remote.mydomain.com.au"