failed to run jupyterhub when changing default port - jupyter

I'm trying to set up jupyterhub. The 8000 is used for a different program, so I have to use a different port.
I change the file /etc/jupyterhub/jupyterhub_config.py add/uncomments:
c.JupyterHub.hub_port = 9003
c.JupyterHub.ip = '111.111.11.1'
c.JupyterHub.port = 9002
c.ConfigurableHTTPProxy.api_url = 'http://127.0.0.1:9000'
when I tried to running jupyterhub, I got the error:
[W 2020-06-03 14:48:48.930 JupyterHub proxy:554] Stopped proxy at pid=47639
[W 2020-06-03 14:48:48.932 JupyterHub proxy:643] Running JupyterHub without SSL. I hope there is SSL termination happening somewhere else...
[I 2020-06-03 14:48:48.932 JupyterHub proxy:646] Starting proxy # http://111.111.11.1:9002/
14:48:49.301 [ConfigProxy] info: Proxying http://111.111.11.1:9002 to (no default)
14:48:49.307 [ConfigProxy] info: Proxy API at http://127.0.0.1:9000/api/routes
14:48:49.315 [ConfigProxy] error: Uncaught Exception
[E 2020-06-03 14:48:49.437 JupyterHub app:2718]
Traceback (most recent call last):
File "/home/user/miniconda/2020.02/python/3.7/lib/python3.7/site-packages/jupyterhub/app.py", line 2716, in launch_instance_async
await self.start()
File "/home/user/miniconda/2020.02/python/3.7/lib/python3.7/site-packages/jupyterhub/app.py", line 2524, in start
await self.proxy.get_all_routes()
File "/home/user/miniconda/2020.02/python/3.7/lib/python3.7/site-pack#c.JupyterHub.hub_ip = '127.0.0.1'
ages/jupyterhub/proxy.py", line 806, in get_all_routes
resp = await self.api_request('', client=client)
File "/home/user/miniconda/2020.02/python/3.7/lib/python3.7/site-packages/jupyterhub/proxy.py", line 774, in api_request
result = await client.fetch(req)
tornado.httpclient.HTTPClientError: HTTP 403: Forbidden
What is the correct way to install jupyterhub on a port other than 8000?
Thanks.

I think some of these parameters are now obsolete, so it may depend which version you are running, but I'll assume JupyterHub 1.0+.
There are a few different services that make up JupyterHub, and the 'hub' service, confusingly, as not actually the one you are concerned with. The proxy is the main entrypoint to the application, and it proxies traffic to the hub by default, and to specific user Jupyter servers if the traffic is to a /user/ URL.
In addition, the 'hub' service also has an API endpoint that user servers can access directly (this doesn't go through the proxy). And the proxy has an extra API endpoint too, for direct access from the hub...
It is the proxy service that defaults to port 8000. To change to 80, for example try this:
## The public facing URL of the whole JupyterHub application.
#
# This is the address on which the proxy will bind. Sets protocol, ip, base_url
c.JupyterHub.bind_url = 'https://0.0.0.0:80'

Related

Expose mongodb using cloudflare zero trust tunnels and connect via pymongo

Hi I am currently trying to set up a mongo db on my home server and expose it to the internet using cloudflare tunnels.
I have a service up and running and have the following for the connection.
client = MongoClient('<DATABASE_URL>')
I get this error...
pymongo.errors.InvalidURI: Invalid URI scheme: URI must begin with 'mongodb://' or 'mongodb+srv://'
I am tunneling the default ip that mongo gives you.
UPDATE
I tested connecting to the db and just printing the database to the console. I got this result
Database(MongoClient(host=['<my_domain>:27107'], document_class=dict, tz_aware=False, connect=True), 'test_db')
I assume that because it says "connect=true" that means it is connecting to the database now.
I tried to add a collection to the database using an example I got online and this is the error I received...
Traceback (most recent call last):
File "/home/michael/mongo.py", line 18, in <module>
x = mycol.insert_one(mydict)
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/collection.py", line 628, in insert_one
self._insert_one(
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/collection.py", line 569, in _insert_one
self.__database.client._retryable_write(acknowledged, _insert_command, session)
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/mongo_client.py", line 1475, in _retryable_write
with self._tmp_session(session) as s:
File "/home/michael/anaconda3/lib/python3.9/contextlib.py", line 119, in __enter__
return next(self.gen)
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/mongo_client.py", line 1757, in _tmp_session
s = self._ensure_session(session)
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/mongo_client.py", line 1740, in _ensure_session
return self.__start_session(True, causal_consistency=False)
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/mongo_client.py", line 1685, in __start_session
self._topology._check_implicit_session_support()
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/topology.py", line 538, in _check_implicit_session_support
self._check_session_support()
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/topology.py", line 554, in _check_session_support
self._select_servers_loop(
File "/home/michael/anaconda3/lib/python3.9/site-packages/pymongo/topology.py", line 238, in _select_servers_loop
raise ServerSelectionTimeoutError(
pymongo.errors.ServerSelectionTimeoutError: No servers found yet, Timeout: 30s, Topology Description: <TopologyDescription id: 63d172246419f5effc5e32d3, topology_type: Unknown, servers: [<ServerDescription ('<my_domain>', 27107) server_type: Unknown, rtt: None>]>
For reference this is what my pymongo test file looks like.
mongo.py
import pymongo
con = pymongo.MongoClient("mongodb://<my_domain>:27107")
db = con["test_db"]
mycol = db["customers"]
print(mycol)
print(db)
mydict = { "name": "John", "address": "Highway 37" }
x = mycol.insert_one(mydict)
If it's a standard installation, you need to make sure cloudflare tunnel is exposing port 27017. The ingress rule must be:
tcp://localhost:27017
To connect, just use:
pymongo.MongoClient("mongodb://user:psw#host.YourTLD/table")
It's a good idea to activate authentication if you're exposing the whole server to the internet. You can do it by setting authentication on the mongodb server, or at the cloudflare zero trust edge following this guide:
https://developers.cloudflare.com/cloudflare-one/tutorials/mongodb-tunnel/
I guess this is the case here:
you have a locally deployed mongodb (not some external VM)
you've set a Cloudflare tunnel in order to expose mongodb over dns
and you are having problems to connect to mongodb using that dns
So I've recently been trying to do the same, and I got over it with these steps:
First off, make sure that your service type, in Cloudflare Zero Trust, is TCP
URL is probably localhost, make sure you specified port
download cloudflared: Apple Silicon & everything else probably
run this on your local machine that you want to connect from: cloudflared access tcp --hostname <hostname you've set on Cloudflare ZT> --url <url you want to be forwarded to>. For example: cloudflared access tcp --hostname mongo.example.com --url localhost:3000
Then try to connect with your app to the localhost:3000.
How does this work?
Well, first you install cloudflared service, which forwards encrypted connection from an app on your machine to the outer internet.
You can protect access to that forwarded service/app using access rules. I also recommend protecting your app/service, you can do it from MongoDB or Cloudflare ZT, or both.
Then, you run cloudflared app on your target machine
connect to Cloudflare servers which forwards your MongoDB instance connection to the specified port on your local machine
you can access it as its local deployment

Barnyard2 syslog output missing program name

I am setting a security-onion instance that monitors the network and uses snort to inspect the traffic. I have configured barnyard2 to forward the logs to an external Syslog server using the line:
output alert_syslog_full: sensor_name so-ens192, server 10.0.0.132, protocol udp, port 514, operation_mode default
the Syslog server receives the alerts but it is unable to identify what is the application that generated the logs.
Instead of receiving something like:
Nov 12 09:33:50 barnyard2[62642]: [1:10482:6] ET INFO Session Traversal Utilities for NAT (STUN Binding Request obsolete rfc 3489 CHANGE-REQUEST attribute change IP flag false change port flag false) [Classification: Generic Protocol Command Decode] [Priority: 3]: <em0> {UDP} 10.0.15.198:15843 -> 74.125.140.127:19302
I receive it without the barnyard2[62642] part as such:
Aug 6 15:53:04 10.0.0.204 [1: 2025705:2] ET POLICY SMB2 NT Create AndX Request For a Powershell .ps1 File [Classification: Potentially Bad Traffic] [Priority: 2]: <so-ens192-1> {TCP} 10.0.0.3:31055 -> 10.0.0.210:445
Any idea what can be wrong with the configuration?

EAC Admin Console is not opening up?

When I try to hit my site, I am getting the following error:
Error Tue May 10 16:54:40 IST 2016 1462879480679
/atg/endeca/assembler/droplet/InvokeAssembler A problem occurred
assembling the content for content item /content/Web/Home Pages. The
response received was {previewModuleUrl=http://localhost:8006/ifcr,
#type=ContentSlot, atg:currentSiteProductionURL=www.local.com:7103,
canonicalLink=com.endeca.infront.cartridge.model.NavigationAction#49dded95,
ruleLimit=1, #error=com.endeca.infront.content.ContentException:
com.endeca.navigation.ENEConnectionException: Error establishing
connection to retrieve Navigation Engine request
'http://localhost:15000/graph?node=0&profiles=NoPriceRange|site&offset=0&nbins=0&merchdebug=1&irversion=640'.
Tried all: '2' addresses, but could not connect over HTTP to server:
'localhost', port: '15000' Check MDEX Logs and specified query
parameters. , contentCollection=/content/Web/Home Pages}. Servicing
the error open parameter.
When I try to access EAC Admin Console to restart MDEX Engine, it is not getting loaded. Why that might be?
Ensure your endeca servers are running. Try to access localhost:8500/cas?wsdl
Is the Dgraph port provided as 15000 in all configurations?

Error when getting the Info from Config Server

I am configuring an Eureka client app, but always the registered port result in 80.
The server config is obtained from Eureka with auto-discovery enabled, when auto-discovery is disabled the port is registered correctly.
The port of the app is assigned only from the command line (--server.port=8080) and deleted in all other properties files (app.yaml, boostrap.yaml and in the config server git repo)
I have notice that in this code:
EurekaClientConfiguration.java
if (port != 0 && instanceConfig.getNonSecurePort() == 0) {
instanceConfig.setNonSecurePort(port);
}
The instanceConfig.getNonSecurePort() never is 0, due to this, the nonSecurePort property is never changed.
I have to register the port property in some other place?
Edited to add some detail:
I mean that my bootstrap.yml has the following lines:
cloud:config:discovery:enabled: true
The yml config is in a github repository and doesn’t have the port assigned
The app is running in the port 8082 with the app param --server.port=8082 But when it is registered in Eureka the port is always 80 instead of 8082
<port enabled="true">8082</port>
<securePort enabled="false">443</securePort>
This cause every based ribbon invocation doesn’t get the correct URL.
I notice that the port is setting correctly in this handler event after the init
EurekaClientConfiguration.java:
public void onApplicationEvent(EmbeddedServletContainerInitializedEvent event) {
...
EurekaClientConfiguration.this.port = event.getEmbeddedServletContainer().getPort();
But the flag "running" is active now and doesn't have any effect
Thanks a lot for your help

Nginx can't access a uWSGI unix socket on CentOS 7

I have configured uWSGI to serve my Django app on a unix socket, and Nginx as a proxy to this socket. The server is running CentOS 7. I think I have configured Nginx so that it has permission to read and write to uWSGI's socket, but I'm still getting a permission denied error. Why can't Nginx access the uWSGI socket on CentOS 7?
[uwsgi]
socket=/socket/uwsgi.sock
virtualenv=/home/site/virtsite/
chdir=/home/site/wsgitest/
module=wsgitest.wsgi:application
vhost = true
master=True
workers=8
chmod-socket=666
pidfile=/home/site/wsgitest/uwsgi-master.pid
max-requests=5000
chown-socket=nginx:nginx
uid = nginx
gid = nginx
listen.owner = nginx
listen.group = nginx
server {
listen 80;
location / {
uwsgi_pass unix:///home/site/wsgitest/uwsgi.sock;
include uwsgi_params;
}
}
uwsgi --ini uwsgi.ini (as root)
ls -l /home/site/wsgitest/uwsgi.sock
srwxrwxrwx. 1 nginx nginx 0 Oct 13 10:05 uwsgi.sock
2014/10/12 19:01:44 [crit] 19365#0: *10 connect() to unix:///socket/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 2.191.102.217, server: , request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///socket/uwsgi.sock:", host: "179.227.126.222"
The Nginx and uWSGI configurations are correct. The problem is that SELinux denied Nginx access to the socket. This results in a generic access denied error in Nginx's log. The important messages are actually in SELinux's audit log.
# show the new rules to be generated
grep nginx /var/log/audit/audit.log | audit2allow
# show the full rules to be applied
grep nginx /var/log/audit/audit.log | audit2allow -m nginx
# generate the rules to be applied
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
# apply the rules
semodule -i nginx.pp
You may need to generate the rules multiple times, trying to access the site after each pass, since the first SELinux error might not be the only one that can be generated. Always inspect the policy that audit2allow suggests creating.
These steps were taken from this blog post which contains more details about how to investigate and what output you'll get.
Configure your uwsgi.ini with uid and gid user.
#uwsgi.ini
uid = nginx
gid = nginx
Regards,
I wished I could comment :(
Everything looks fine from here except unix socket path
unix:///socket/uwsgi.sock failed (2: No such file or directory)
Docs says it has just one slash
uwsgi_pass unix:/tmp/uwsgi.socket;