i'm not able to do Publisher/Subscriber in rabbitmq in ubuntu22.04, i'm not finding anything about it. I use docker for this, I can create the management with port 8080:15672, I cannot use 5672. And when I send some code to Publisher/Subscriber nothing appears in the management, (obs: I used http//localhost:8080 to access rabbitmq management)
Did you open traffic redirection to port 5672? For eg. If you are using docker run, then -p 5672:5672
Related
I came across the documentation of jupyter-server-proxy which has some useful tools but I am not sure how to make use of.
Assume I create a jupyter server on the VM on port 8888, normally I will use ssh port-forwarding to interact with it locally with ssh -L . However, I would like to automate now if I start a service such as Spark or Prometheus...etc that creates a dashboard service at 8080 (Spark) or 1234 (any other), is there an automated way that it forwards the port locally as part of jupyter so that I can access the service at, say for spark at: https://localhost:8888/port/8080 ?
Any education is much appreciated as I'm not even sure what is the correct terminology to search on.
I've set up tailscale and connected to an exit node on my VPS on vultr.com. Predictably, I was kicked out and couldn't reconnect, as the VPS's public IP address has changed.
I can reboot the VPS and try again. What steps will I need to take? Does my VPS running behind an exit node even have a unique public address (which?), or does it need to be set up for something like port forwarding?
From looking at tailscale documentation, it looks like they came up with their own ssh, why? Why is the standard ssh inadequate for the purpose? I am not the admin of my tailscale network, and the admin is swamped right now. What can I do?
SSH uses TCP as transport and therefore requires the (srcaddr, srcport, dstaddr, dstport) tuple to be constant over the connection's lifetime.
I believe that since tailscale rotates connections dynamically, it is more suitable for use by clients than servers in a traditional client-server model, unless it provides an 'internal' virtual network over the distributed transport (which would kind of defeat the purpose of covering your tracks).
If you want to connect to your VPS over tailscale, you need to use their tools probably because of that. You can still connect directly to your VPS, though, through plain Internet, if it has any address of its own, and is not firewalled away (or similarly, NATed away). Your provider should either show you the address, or even better, provide access to out-of-band (like serial-port) command line access, where you can query the current addresses using commands like ip addr show.
In your Tailscale Admin console you should be able to see the machine's IP. Just use normal ssh and login that way.
So instead of ssh user#8.8.8.8 you'd do ssh user#100.64.0.1. Tailscale's own ssh client is useful if you want to hook deeper into their MagicDNS stuff, but it's not meant to be the only way to ssh into your machine.
If you run into errors, ping the machine you want to connect to (tailscale ping vps-machine-name). That should help you debug any tailscale client connection problems.
Rabbit MQ URL looks like :
BROKER_URL: "amqp://user:password#remote.server.com:port//vhost"
This is not clear where we can find the URL, login and password of RabbitMQ
when we need to acccess from remote worker (outside of Localhost).
In other way, how to set RabbitMQ IP adress, login and password from Celery / RabbitMQ
You can create new user for accessing your RabbitMQ broker.
Normally port used is 5672 but you can change it in your configuration file.
So suppose your IP is 1.1.1.1 and you created user test with password test and you want to access vhost "dev" (without quotes) then it will look something like this:
amqp://test:test#1.1.1.1:5672/dev
I will recommend to enable RabbitMQ Management Plugin to play around RabbitMQ.
https://www.rabbitmq.com/management.html
To add to the accepted answer:
As of 2022, the default username and password are guest
In my experience, ignoring vhost is safe while getting started with RabbitMQ
If using RabbitMQ as part of a Docker Compose setup (e.g. for testing), other containers in the same application should be able to access RabbitMQ via its service name. For example, if the name of the service in docker-compose.yml is rabbitmq, passing amqp://guest:guest#rabbitmq:5672/ should work
Hi I'm currently working on a side project. In this project I'll have a central server that will need to connect to several remote docker daemons. My problem is with authentication.
Given that the project will be hosted on Digitalocean, my first thought suggested that I'll accept only connections from the private networking interface. The problem is that that interface is accessible by all other servers in the same datacenter.
Second thought is to allow only requests from the central server using the DOCKER_HOST config, the problem is that if I understand correctly the if the private IP of the centeral server get known, the IP can be spoofed.
Third thought is to enable TLS ( https://docs.docker.com/articles/https/ ), I've never dealt with those things before and the tutorial is unclear for me, I lack the knowledge of the terminologies and it's being used heavily.
So basically the problem is that I have a central client and multiple remote docker hosts, what is the best way to connect to them? Thank you.
EDIT: I managed to solve the problem using HTTP authentication by running nginx as a proxy in front of the docker daemon.
My understand is you are trying to build a docker cluster, which can manage all nodes from one single central server.
this is very likely docker's Docker Swarm project, from their doc, they give some simple idea how this is work:
open a TCP port on each node for communication with the swarm manager
install Docker on each node
create and manage TLS certificates to secure your swarm
Sorry this should post as a comment but I do not have enough rep to do that.
RabbitMQ starts up just fine, but the shovel plugin status is listed as "starting".
I'm using the following rabbitmq.config:
Each broker is running on a separate AWS instance. The remote server is windows 2008 server, the local server is Amazon Linux.
[{rabbitmq_shovel,
[{shovels,
[{scrape_request_shovel,
[{sources, [{broker,"amqp://test_user:test_password#localhost"}]},
{destinations, [{broker, "amqp://test_user:test_password#ec2-###-##-###-###.compute-1.amazonaws.com"}]},
{queue, <<"scp_request">>},
{ack_mode, on_confirm},
{publish_properties, [{delivery_mode, 2}]},
{publish_fields, [{exchange, <<"">>},
{routing_key, <<"scp_request">>}]},
{reconnect_delay, 5}
]}
]
}]
}].
Running the following command:
sudo rabbitmqctl eval 'rabbit_shovel_status:status().'
returns:
[{scrape_request_shovel,starting,{{2012,7,11},{23,38,47}}}]
According to This question, this can result if the users haven't been set up correctly on the two brokers. However, I've double-checked that I've set up the users correctly via rabbitmqctl user_add on both machines -- have even tried it with a different set of users, to be sure.
I also ran an nmap scan of port 5672 on the remote host to verify is was up and running on that port.
UPDATE Problem isn't solved but this does appear to be a result of connection problems with the remote server. I changed "reconnect_delay" to 0 in my config file, to avoid having shovel infinitely re-try the connection. Highly recommend others with this problem do this as well, as it allows you to get error messages out of rabbit_shovel_status. In my case I got the following error:
[{scrape_request_shovel,
{terminated,
{{badmatch,{error,access_refused}},
[{rabbit_shovel_worker,make_conn_and_chan,1},
{rabbit_shovel_worker,handle_cast,2},
{gen_server2,handle_msg,2},
{proc_lib,init_p_do_apply,3}]}},
{{2012,7,12},{0,4,37}}}]
Answering my own question here, in case others encounter this issue. This error (and also a timeout error if you get it, {{badmatch,{error,etimedout}}, ), is almost certainly a communications problem between the two machines, most likely due to port access / firewall settings.
There were a couple of dumb things I was doing here:
1) Was using the wrong DNS for my remote EC2 instance (D'oh! really dumb -- can't tell you how long I spent banging my head against the wall on this one...). Remember that stopping and starting your instance generates a new DNS, if you don't have an elastic IP associated with the instance.
2) My remote instance is a windows server, and I realized you have to open up port 5672 both in windows firewall and in EC2 security groups -- there are two overlapping levels of access controls here, and opening up the port in the EC2 management console isn't sufficient if your machine is windows server on EC2, as you also have to configure the windows server firewall.