Problem: to get the command working here. My domain is http://cs.edu.com/user/share_dir, but I cannot get the command working by typing it to a browser:
http://cs.edu.com/user/share_dir:8000
Question: How can I get the command working?
Your URL is incorrect. The port number should be specified after the domain name:
http://cs.edu.com:8000/
Some other things you should keep in mind:
If this is a shared host, port 8000 might already be in use by someone else
The host might not be accessible from 'outside' of the network, due to firewall restrictions on non-standard ports
The system you see internally could map to a different system outside, so the domain/hostname could be different from what you expect.
Related
Got a bit problem with ZeroMQ socket on trying to .bind() on 0.0.0.0:5555 address, when tried to run it in Docker container via a Rancher Cattle.
Every time I try to run it, I'm getting the same error:
zmq.error.ZMQError: Address already in use.
Tried to do EXPOSE 5555 and EXPOSE 5555/tcp in my Dockerfile, but it did not help me.
Here is a part of my code:
...
self.context = zmq.Context()
self.socket = self.context.socket(zmq.PUB)
self.socket.bind('tcp://%s:%d' % ('0.0.0.0', 5555))
...
Maybe somebody had the same problem. How to solve it?
ZeroMQ API defines 3-ways to go:
Assigning a local address to a socket
When assigning a local address to a socket using zmq_bind() with the tcp:// transport, the endpoint shall be interpreted as an interface followed by a colon and the TCP port number to use.
An interface may be specified by either of the following:
- The wild-card *, meaning all available interfaces.
- The primary IPv4 address assigned to the interface, in its numeric representation.
- The interface name as defined by the operating system.
Interface names are not standardised in any way and should be assumed to be arbitrary and platform dependent. On Win32 platforms no short interface names exist, thus only the primary IPv4 address may be used to specify an interface.
So, at least one ought make the job progress.
After two hours of debugging i tried to make .bind_to_random_port() and noticed, that my app in Docker starts via 4 Gunicorn workers. So after first worker started, three another workers can not bind to the same port. Be aware of binding to only one port while you have multiple threaded or multiple workers application.
i have read the tutorial below ,but still can not solve this problem.
https://github.com/shadowsocks/shadowsocks/wiki/Configuration-via-Config-File
The program can't bind the socket. This might happen when the IP / port combination is in use already or if there are OS limitation, like firewall restrictions or using a port below 1024 as normal user.
I hope this doesn't cross into superuser territory.
So I have an embedded linux, where system processes are naturally quite stripped. I'm not quite sure which system process monitors to physical layer and starts a dhcp client when network cable is plugged in, but i made one myself.
ยจ
The problem is, that if i have a python script, using http connections, running before i have an IP address, it will never get a connection. Even after i have a valid IP, the python still has
"Temporary error in name resolution"
So how can I get the python to realize the new connection available, without restarting the script?
Alternatively , am I missing some normal procedure Linux runs normally at network cable connect.
The dhcp client I am using is udhcpc and python version is 2.6. Using httplib for connections.
Sounds like httplib caches /etc/resolv.conf which is updated after your DHCP client obtains an IP.
You might consider writing a wrapper script that waits until an IP address is obtained, then calls your python script.
Alternatively, you could try to, within your python script, not open any socket connections until you have acquired an IP address and /etc/resolv.conf updated.
Edit
httplib uses socket.create_connection() which, after some searching, I found does cache /etc/resolv.conf. (Well, it seems that the embedded version of libc is actually doing the caching).
You could try SugarLabs' solution, although I can't speak to it's effectiveness.
it might be that one of the python modules is caching the state of the network, and so it isn't using the latest settings. Try and reload all the network related modules. A simple example of this is:
import sys, socket, urllib
for i in [sys, socket, urllib]:
reload(i)
if that doesn't work look around in sys.modules to see what else got imported, and try more modules there. A more extreme version of the reloading would be the code below, that you could try as a last ditch effort.
code
import sys
print 'reloading %s modules ' % len(sys.modules)
for name, module in sys.modules.items():
try:
reload(module)
except:
print 'failed to import %s' % name
output
reloading 42 modules
failed to import __main__
failed to import encodings.encodings
failed to import encodings.codecs
failed to import lazr
failed to import encodings.__builtin__
After alot more research, the glibc problem jedwards suggested, seemed to be the problem. I did not find a solution, but made workaround for my usecase.
Considering I only use one URL, I added my own "resolv.file" .
A small daemon gets the IP address of the URL when PHY reports cable connected. This IP is saved to "my own resolv.conf". From this file the python script retrieves the IP to use for posts.
Not really a good solution, but a solution.
I am running a Virtual Machine which gives the following values and when the code is run (by doing some action on the website)
socket.getfqdn()
x-vps-01.abc.it
socket.gethostname()
x-vps-01
socket.gethostbyname(socket.getfqdn())
216.185.103.35
socket.gethostbyname(socket.gethostname())
78.47.171.19
Please note that, when I log into the terminal and run the above, I always get
78.47.171.19
I tried what you did on a Linux box. Maybe you should state what OS and network situation you are running on.
Using strace I found that socket.getfqdn() is using information provided in the file /etc/hosts while socket.gethostname() only prints data from the result of the system call uname(); basically you could say the one asks the network module while the other asks the kernel. Both have an answer to your question but they do not necessarily match because they have different views on that matter.
Calling socket.gethostbyname() also queries the network module (searches the contents of the file /etc/hosts for a match in my case). Giving the answer of the kernel to the network function isn't really what you should do. In most cases this will work nevertheless. You found a spot in which it produced strange results.
I think that this issue is caused by Python bug specific to MacOS, the one that I mention at https://stackoverflow.com/a/53143006/99834
Good news: there is a workaround you can run on your machine.
I wrote a simple python program to play and pause banshee music player.
While its working on my own machine, I have trouble doing it to a remote computer, connected to the same router (LAN).
I edited the session.conf of the remote machine, to add this line:
<listen>tcp:host=localhost,port=12434</listen>
and here is my program:
import dbus
bus_obj=dbus.bus.BusConnection("tcp:host=localhost,port=12434")
proxy_object=bus_obj.get_object('org.bansheeproject.Banshee',
'/org/bansheeproject/Banshee/PlayerEngine')
playerengine_iface=dbus.Interface(proxy_object,
dbus_interface='org.bansheeproject.Banshee.PlayerEngine')
var=0
while (var!="3"):
var=raw_input("\nPress\n1 to play\n2 to pause\n3 to exit\n")
if var=="1":
print "playing..."
playerengine_iface.Play()
elif var=="2":
print "pausing"
playerengine_iface.Pause()
This is what i get when i try to execute it
Traceback (most recent call last):
File "dbus3.py", line 4, in <module>
bus_obj=dbus.bus.BusConnection("tcp:host=localhost,port=12434")
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 125, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket "localhost:12434" Connection refused
What am I doing wrong here?
should i edit /usr/lib/python2.7/dist-packages/dbus/bus.py
UPDATE:
ok, here is the deal
when i add
<listen>tcp:host=192.168.1.7,port=12434</listen>
to to /etc/dbus-1/session.conf, then reboot, hoping it would start listening on reboot,
It never boots. It gets stuck on loading screen and occasionally, a black screen with the following text flashes:
Pulseaudio Configured For Per-user Sessions Saned Disabled;edit/etc/default/saned
so, when i go ctrl+alt+f1 , change session.conf to original state and reboot, it boots properly.
Whats all that about?
How can I make dbus daemon listen for tcp connections, without encountering problems?
I recently needed to set this up, and discovered that the trick is: order matters for the <listen> elements in session.conf. You should make sure the TCP element occurs first. Bizarre, I know, but true, at least for my case. (I see exactly the same black screen behavior if I reverse the order and put the UNIX socket <listen> element first.)
Also, prepending the TCP <listen> tag is necessary, but not sufficient. To make remote D-Bus connections via TCP work, you need to do three things:
Add a <listen> tag above the UNIX one, similar to this:
<listen>tcp:host=localhost,bind=*,port=55556,family=ipv4</listen>
<listen>unix:tmpdir=/tmp</listen>
Add a line (right below the <listen> tags is fine) that says:
<auth>ANONYMOUS</auth>
Add another line below these that says:
<allow_anonymous/>
The <auth> tag should be added in addition to any other <auth> tags that may be contained in your session.conf. In summary, your session.conf should contain a snippet that looks like this:
<listen>tcp:host=localhost,bind=*,port=55556,family=ipv4</listen>
<listen>unix:tmpdir=/tmp</listen>
<auth>ANONYMOUS</auth>
<allow_anonymous/>
After doing these three things, you should be able to connect to the session bus remotely. Here's how it looks when specifying a remote connection in D-Feet:
Note that, if you want to connect to the system bus, too, you need to make similar changes to /etc/dbus-1/system.conf, but specify a different TCP port, for example 55557. (Oddly enough, the element order appears not to matter in this case.)
The only weird behavior I've noticed in this configuration is that running Desktop apps with sudo (e.g., sudo gvim) tends to generate errors or fail outright saying "No D-BUS daemon running". But this is something I need to do so rarely that it hardly matters.
If you want to send to a remote machine using dbus-send, you need to set DBUS_SESSION_BUS_ADDRESS accordingly, e.g., to something like:
export DBUS_SESSION_BUS_ADDRESS=tcp:host=localhost,bind=*,port=55556,family=ipv4
This works even if the bus you want to send to is actually the system bus of the remote machine, as long as the setting matches the TCP <listen> tag in /etc/dbus-1/system.conf on the target. (Thanks to Martin Vidner for this tip. Until I stumbled across his answer to this question, I didn't believe dbus-send supported remote operation.)
UPDATE: If you're using systemd (and want to access the system bus), you might also need to add a line saying ListenStream=55557 to /lib/systemd/system/dbus.socket, like so:
[Socket]
ListenStream=/var/run/dbus/system_bus_socket
ListenStream=55557 # <-- Add this line
UPDATE2: Thanks to #altagir for pointing out that recent versions of D-Bus will enable AppArmor mediation on systems where it's available, so you may also need to add <apparmor mode="disabled"/> to session.conf/system.conf for these instructions to work.
since dbus 1.6.12 (e.g. kubuntu 13.10), your connection will also be rejected unless you add to your dbus config file (either /etc/dbus-1/mybus.conf or the interface requiring remote access i.e. system.d/my.interface.conf)
<apparmor mode="disabled"/>
UPDATE: After struggling to create a apparmor profile allowing the service to connect to the custom dbus-daemon, it seems the connection is always rejected due to a bug in DBUS... So for now we MUST disable apparmor whenever you use tcp=... Bug fix targetted for 14.04
I opened a bug at bugs.launchpad.net following discussion here with Tyler Hicks:
The AppArmor mediation code only has the ability to check peer labels
over UNIX domain sockets. It is most likely seeing an error when
getting the label and then refusing the connection.
Note:
the disable flag is not recognized by dbus < 1.6.12, so you need to package different versions of mydaemon.conf depending on systen), else dbus-daemon will fail on launch if no apparmor... I used for now in my CMakeLists.txt :
IF(EXISTS "/usr/sbin/apparmor_status")
install(FILES dbus_daemon-apparmordisabled.conf RENAME dbus_daemon.conf DESTINATION /etc/dbus-1/ )
ELSE (EXISTS "/usr/sbin/apparmor_status")
install(FILES dbus_daemon.conf DESTINATION /etc/dbus-1/ )
ENDIF(EXISTS "/usr/sbin/apparmor_status")
Another thanks #Shorin, and another FYI - I had to do something like this to make mine work:
<listen>tcp:host=localhost,bind=0.0.0.0,port=55884</listen>
Note the bind=0.0.0.0 - the bind=* didn't work for me, and I left out the family=ipv4 part. I'm on Ubuntu 12.04. I did use netstat on the remote machine to confirm dbus was listening on the port and telnet from local to confirm the port was open.
netstat -plntu | grep 55884
tcp 0 0 0.0.0.0:55884 0.0.0.0:* LISTEN 707/dbus-daemon
You have to see something like 0 0.0.0.0:55884 and not something like 0 127.0.0.1:55884.