ubuntu@passbolt2:/usr/share/nginx$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
ubuntu@passbolt2:/usr/share/nginx$
If there is still no response from your client browser, try getting a response with the command line on the server again:
Okay, now weāre getting the passbolt page.:
ubuntu@passbolt2:/usr/share/nginx$ curl -L https://passbolt.mydomain.co.uk
<!doctype html>
<html class="passbolt no-js version launching no-passboltplugin" lang="en">
<head>
<meta charset="utf-8"/>
<title>Passbolt | Open source password manager for teams</title>
<!--
____ __ ____
/ __ \____ _____ ____/ /_ ____ / / /_
/ /_/ / __ `/ ___/ ___/ __ \/ __ \/ / __/
/ ____/ /_/ (__ )__ ) /_/ / /_/ / / /_
/_/ \__,_/____/____/_.___/\____/_/\__/
Open source password manager for teams
Copyright (c) Passbolt SA (https://www.passbolt.com)
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see http://www.gnu.org/licenses/.
-->
<meta name="description" content="Open source password manager for teams">
<meta name="keywords" content="Passbolt, password manager, online password manager, open source password manager">
<meta name="robots" content="noindex, nofollow">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="shortcut icon" type="image/x-icon" href="https://passbolt.mydomain.co.uk/favicon.ico" />
<link rel="icon" href="https://passbolt.mydomain.co.uk/favicon_32.png" sizes="32x32" />
<link rel="icon" href="https://passbolt.mydomain.co.uk/favicon_57.png" sizes="57x57" />
<link rel="icon" href="https://passbolt.mydomain.co.uk/favicon_76.png" sizes="76x76" />
<link rel="icon" href="https://passbolt.mydomain.co.uk/favicon_96.png" sizes="96x96" />
<link rel="icon" href="https://passbolt.mydomain.co.uk/favicon_128.png" sizes="128x128" />
<link rel="icon" href="https://passbolt.mydomain.co.uk/favicon_192.png" sizes="192x192" />
<link rel="icon" href="https://passbolt.mydomain.co.uk/favicon_228.png" sizes="228x228" />
<base href="https://passbolt.mydomain.co.uk/">
<script src="https://passbolt.mydomain.co.uk/js/app/stylesheet.js?v=3.7.1" id="stylesheet-manager" data-file="api_authentication.min.css" cache-version="3.7.1"></script></head>
<body>
<!-- main -->
<div id="container" class="page ">
</div>
<script src="https://passbolt.mydomain.co.uk/js/app/api-vendors.js?v=3.7.1" cache-version="3.7.1"></script><script src="https://passbolt.mydomain.co.uk/js/app/api-triage.js?v=3.7.1" cache-version="3.7.1"></script></body>
</html>
@unboostedvtak So if you still cannot access via the browser, I would look at the firewall settings or something like a fail2ban service that might be running and blocking your client ip due to too many failures, etc.
You could check the /var/log/ufw
for errors, if you have ufw
enabled.
Sometimes I run tcptrack -i <interfacename>
to see what activity is coming in. But if there is no activity on the server at all, it appears there is something else in the network that has changed.
Iāve tried accessing it through a different IP, phone, over browser, on mobile data, and getting Address Unreachable.
Never used tcptrack before, it seems pretty neat.
I ran a tcpdump as well during that, and thatās what Iām gettingā¦
Other public organizations are clearly hitting your NGINX logs with searches, so is there a rule somewhere that blocks internal network ip access? Or does your client machine have a block on returned responses maybe?
I should have clarified, the previous, is coming from the IP I am accessing from.
Same when I used my phoneās browser, from the IP of the phone.
It does look like the traffic is hitting the server.
That is what it looks like when something is getting blocked, in my opinion. When the traffic is getting through it looks like:
My only established state there is my SSH connection to the server, any other attempts at connecting I get the āSYN_SENTā
Iāll be honest, Iām now a bit out of my element hereā¦
Interestingly enough though, if I leave the page open, this pops up periodically:
Local IP over what looks like an APIPA address over 80 established?
Is there a management system handling this particular VM/server? Like cpanel or Virtualmin? Or, is this a plain-vanilla Ubuntu 22 install? It seems like there are overriding processes occurring.
Itās a VM up in Oracle cloud. Vanilla Ubuntu as far as I can tell. Never used Virtualmin or CPanel before, but have used Webmin, if itās a similar thing I donāt see whatās stopping me from getting that put onto there.
No, we would prefer plain vanilla. @AnatomicJC any ideas?
Server is running IPtables. It was working fine before I changed SMTP details, I donāt see the relation between the issues weāre having now from changing SMTP credentials ā¦
Only rules Iāve explicitly added, on top of what Oracle pre-loads is to allow 80 and 443 in, it should allow everything out of itself by default from my understanding.
With the rules added, it was working. It all went wrong changing credentialsā¦
When I ran nginx -t explicitly on the config file, it was looking for that config in /usr/share/nginx but it wasnāt in there, do you think that may have anything to do with it maybe? Missing copy or symlink maybe?
Typically, nginx.conf will reference the location of the other config files. You could check that: /etc/nginx/nginx.conf
The nginx test command is going to by default check the entire configuration - I think when you specified a file, you inadvertantly pointed it to a non-existing config file in the /etc/nginx
folder. I think the issue is resolved regarding passbolt. Something is blocking external requests.
Check other logs. syslog, etc.
Pretty much the only thing in syslog is
ubuntu@passbolt2:/var/log$ tail -f /var/log/syslog
Sep 13 16:05:01 passbolt2 CRON[32298]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:06:01 passbolt2 CRON[32315]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:07:01 passbolt2 CRON[32333]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:08:01 passbolt2 CRON[32350]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:09:01 passbolt2 systemd[1]: Starting Clean php session files...
Sep 13 16:09:01 passbolt2 systemd[1]: phpsessionclean.service: Deactivated successfully.
Sep 13 16:09:01 passbolt2 systemd[1]: Finished Clean php session files.
Sep 13 16:09:01 passbolt2 CRON[32441]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Sep 13 16:09:01 passbolt2 CRON[32442]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:10:01 passbolt2 CRON[32484]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:11:01 passbolt2 CRON[32502]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:11:41 passbolt2 systemd[1]: Starting Cleanup of Temporary Directories...
Sep 13 16:11:41 passbolt2 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Sep 13 16:11:41 passbolt2 systemd[1]: Finished Cleanup of Temporary Directories.
I tried to access it again while running the tail command to see if it populated anything⦠Other than that in syslog looks like a cron job every minute or so.
Passbolt seems to be running according to curl now, which is good I guess.
I know you said you added rules to iptables, can we verify?
sudo iptables -L INPUT
āNo route to hostā and ERR_CONNECTION_TIMED_OUT in the browser: each time I encountered this, it was a firewall issue. There is for sure a firewall rule who is blocking connection, a rule on the server, or somewhere else in your Oracle cloud network.
This is what the output is:
ubuntu@passbolt2:~$ sudo iptables -L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp spt:ntp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT icmp -- anywhere anywhere
ubuntu@passbolt2:~$
I canāt lie, I donāt see my 443 rule appearing on thereā¦
Hereās a reference where they explain why they donāt use ufw. https://blogs.oracle.com/developers/post/enabling-network-traffic-to-ubuntu-images-in-oracle-cloud-infrastructure
Mentions iptables steps. I saw you saved the rules but maybe they donāt respect that netfilter command.
You two are ***ing legends.
Got it back up, thank you very much.
Iām guessing the netfilter save actually did nothing. ā though, i have rebooted before, but hey, linuxā¦
Iāve gone into the file for iptables, as suggested in the article you sent, manually entered it in, reloaded the iptables service, nothing, rebooted, itās back up.
Odd that changing smtp details broke it in the first place, but I can confirm that is working with an app password too now.
Thank you!