I have created a simple http server on mininet simple topology host h1 using the following command
h1 python3 -m SimpleHTTPSErver 80 &
and then tried to connect h2 to h1 by using
h2 wget -O - h1
but the connection is refused
Python3 does not have the SimpleHTTPServer module anymore. It has been deprecated and replaced by http.server. I assume you have not looked at the output of these commands.
I have successfully ran the example
python3 http.server 80
on h1. And was then able to connect h2 to it using h1's IP address as follows:
wget -O - 10.0.0.1
Related
Recently I downloaded the new version Keycloak 17.0.0 Quarkus distribution, unzipped and started the Keycloak server by running bin/kc.sh start-dev from my local $KEYCLOAK_HOME directory in a CygWin Bash window. The server is up and running and I have configured my initial admin user. I am also able to login to the Keycloak UI.
There is no cloud environment yet, no fancy configuration, it's only the bare standalone quarkus impl.
Question: How can I gracefull stop/quit/terminate the Keycloak server process? (Ctrl+C does not help in this case, because this command is not really scriptable)
Before moving to v17 I started my experiments with v16.1.0 Wildfly distribution and I was using ${KEYCLOAK_HOME}/bin/jboss-cli.sh --connect --commands="shutdown,quit" to terminate the server. But v17 (quarkus) does not contain the jboss-cli.sh script.
This may not be a graceful stoppage/shutdown but we can still use it in a script until we find a better way.
fuser : an utility to identify processes using files or sockets
If CygWin bash supports Linux fuser command you can try : fuser -k 8080/tcp
Here is what I'm using on Linux
If keycloak is running on its default https port
sudo fuser -k 8443/tcp
If keycloak is running on its http default port
sudo fuser -k 8080/tcp
If you running keycloak on some_custom_prot
sudo fuser -k some_custom_prot/tcp
It looks like capturing the PID and killing that later will work in v17 (I'm not sure this was true for v15 and WildFly):
$ ./keycloak-17.0.1/bin/kc.sh start-dev --http-port=8080 > keycloak.stdout 2>&1 & echo "$!" > keycloak.pid
$ cat keycloak.pid | xargs kill -TERM
Stop
Linux: ./jboss-cli.sh --connect command=:shutdown
Windows: jboss-cli.bat --connect command=:shutdown
I installed localtunnel globaly by runnnig this command npm install -g localtunnel.
After that when I run lt --port 8080, absolutely nothing happens. Does anyone know why?
It appears that the author isn't maintaining Local Tunnel much these days, but there was a helpful comment on the github issue dealing with this. At the time of writing this, you can generate a Local Tunnel with
lt -h "http://serverless.social" -p 8080
Try
lt -p 8080 -h http://localtunnel.me
And in the URL you get, replace the "https" with "http". Maybe don't open it with Google Chrome but with Safari instead, but Google Chrome might work, too.
For more information see: https://github.com/localtunnel/localtunnel/issues/332
It seems like localtunnel is currently down.
Click here to go to the github issues page for more information and updates
run this
lt -h "https://serverless.social" -p 8080
it should work
I ran into the same issue on my raspberry pi. You need to validate your npm and localtunnel installation. Check if you get valid results for npm --version. If not, reinstalling npm will fix the problem. In case you installed localtunnel locally (instead of the -g option), you may have to use the command like:
npx localtunnel --port <port>
I did a simple thing though insecure to host it:
lt --port 443 -h "http://localtunnel.me" -s myhost
and then in another tab:
python3 -m http.server 443
This worked for me.
The consequence was that the device on which I was accessing my site showed complete root directory(I am sure there are configurations to be made to prevent this)
change the port from 8080 to 8000 the issue might be because of on port 8080 there is something already running .
LocalTunnel is refusing to connect when using node 18. I've downgraded to 16 and it's working fine. I don't know the reason, but it seems to be IPv6 related.
If you're having trouble with it, try running with DEBUG:
export DEBUG="localtunnel:*" && lt --port 8080
For reference, this is the error I seen when using node 18 with the DEBUG flag:
localtunnel:client local error connect ECONNREFUSED ::1:3939 +0ms
I get below error while trying to connect to IBM Watson internet of things platform using client certs & mosquitto client. The same certs work fine with node.js client hence I know certs are fine, just some config in mosquitto client which is erroneous.
mosquitto_sub -h dumorg.messaging.internetofthings.ibmcloud.com -p 8883 --capath ./certs/ -t "iot-2/type/dumtype/id/dumid/cmd/+/fmt/json" -v -i g:dumorg:dumtype:dummid --cert ./client.crt --key ./client.key
Connection Refused: not authorised.
When I try to perform same connection using auth-token it goes through fine
$ mosquitto_sub -h dumorg.messaging.internetofthings.ibmcloud.com -p 8883 --capath ./certs/ -t "iot-2/type/dumtype/id/dumid/cmd/+/fmt/json" -v -i g:dumorg:dumtype:dumid -P dumpassword -u use-token-auth
I am also able to successfully connect using certs through another client. I know the certs are fine, and mosquitto command works with auth token. hence issue is some missing/incorrect config in mosquitto due to which IoT platform doesn't like certs used to connect with mosquitto?
Seems mosquitto does not support SNI which is required to connect to MQTT broker on IBM cloud. Manually inserting this patch https://github.com/eclipse/mosquitto/pull/626 and building mosquitto resolved issue. Hope this is merged in main branch in near future.
I like to use scrapyRT to connect all my scraper spiders to the Angular front-end.
The documentation recommends to run in it in production as follows:
docker run -p 9080:9080 -tid -v /home/user/quotesbot:/scrapyrt/project scrapinghub/scrapyrt
This will expose port 9080 to the outside world.
I'm concerned about the safety of this.
How can I properly secure this to avoid bots visiting the end points?
If Scrapyrt is running on the same machine as your frontend, you could make Scrapyrt listen only on localhost:
docker run -p 9080:9080 -tid -v /home/user/quotesbot:/scrapyrt/project scrapinghub/scrapyrt -i 127.0.0.1
That way it will be accessible only from that machine (e.g. from the frontend application).
Otherwise use firewall to allow communication from your frontend machine only.
When running my Dockerfile I need to grab dependencies. This is done using go get ./....
However when doing docker build -t test . it hangs at the go get command.
here is the error message
exec go get -v -d
github.com/gorilla/mux (download)
cd .; git clone https://github.com/gorilla/mux /go/src/github.com/gorilla/mux Cloning into
'/go/src/github.com/gorilla/mux'... fatal: unable to access
'https://github.com/gorilla/mux/': Could not resolve host: github.com
package github.com/gorilla/mux: exit status 128
here is the dockerfile
FROM golang
# Create a directory inside the container to store all our application and then make it the working directory.
RUN mkdir -p /go/src/example-app
WORKDIR /go/src/example-app
# Copy the example-app directory (where the Dockerfile lives) into the container.
COPY . /go/src/example-app
# Download and install any required third party dependencies into the container.
RUN go-wrapper download
RUN go-wrapper install
RUN go get ./...
# Set the PORT environment variable inside the container
ENV PORT 8080
# Expose port 8080 to the host so we can access our application
EXPOSE 8080
# Now tell Docker what command to run when the container starts
CMD ["go-wrapper", "run"]
I assume you're doing that via ssh on another machine. Check if it has a dns server in your /etc/network/interfaces. It should look somehow like this:
iface eth0 inet static
address 192.168.2.9
gateway 192.168.2.1
netmask 255.255.255.0
broadcast 192.168.2.255
dns-nameservers 192.168.2.1 8.8.4.4
DNS servers that "always" work are 8.8.8.8 and 8.8.4.4, both provided by Google. If that doesn't resolve your problem, you should check your internet connection for other misconfigurations, but first try this.