I want to create a XMPP server on my network and then send message to it with python so that this server can restart the target computer on the network , now how can i set up this server and how can i do the rest of the process?
tnx
I am not sure in what context you are trying to do this, but XMPP has been used in context outside of usual chat and instant messengers (e.g. load balancers, rpc, ...).
There can be several ways of doing this. One way I can think right now is by using Jabber RPC xep-0009 which says:
This specification defines an XMPP protocol extension for
transporting XML-RPC encoded requests and responses between two XMPP entities.
The protocol supports all syntax and semantics of XML-RPC except that
it uses XMPP instead of HTTP as the underlying transport.
Workflow wise here is how you can make this work:
You will need a jabber server which is up and running say on host-A
You will need to configure a startup service on other hosts in the network (say on host-B, host-C, host-D). This startup service is nothing but a xmpp client daemon which will start in the background whenever host is started.
This xmpp client configured as startup service are special in the sense that they will accept incoming rpc calls (support for XEP-0009) and execute received commands on the host.
Received RPC commands can be synonymous to shutdown, kill -9 xxxx depending upon your specific needs.
Finally, xmpp client on host-C can send one or more commands wrapped inside an stanza to xmpp client running on host-B.
You can use one of the existing python xmpp client library and simply extend their working examples for your use case. You will also need to check details on how to configure startup service depending upon your Operating System (e.g. update-rc.d for ubuntu or sc.exe for windows)
Related
I would like to create a web service with GoLang that runs either on IIS (7, 8 or 10) or under Tomcat 7.0. We have multiple environments, each with multiple servers, all being Windows 2008 R2, 2012 or 2016. All servers are private (10.x). My goal is to add some REST services to a COTS product that uses both IIS and Tomcat. I'd prefer to avoid gluing nginx or something else onto either server at the risk of impairing the COTS product or having their tech support people not answer the phone. Again .. the servers are only accessible via corporate VPN and are not public internet-facing.
Which server would offer the easiest path to get something working -- Tomcat or IIS?
That's not really about Go, but still there exist at least two solutions I can think of:
Reverse proxying of HTTP requests.
Write a plain Go server serving requests via HTTP.
Maybe turn it into a proper Windows service using golang.org/x/sys/windows/svc.
Deploy it.
If it's to be hosted on the same machine which runs IIS, then it's fine to make it listen on localhost only. Note that it will need a dedicated TCP port to listen on, and you'll need to make it possible for your server to be somehow configurable in this regard.
Set up reverse proxying in your IIS so that it forwards requests coming to whatever (part of an) URL you want to the Go server.
Use FastCGI.
Go supports serving requests over the FastCGI
protocol by means of its standard library,
and IIS suports FastCGI workers.
So it's possible to (re-)write your Go server to use FastCGI
instead of HTTP and then hook it into IIS via this protocol.
The pros and cons of these solutions—as I view them—are:
Serving over plain HTTP is more familiar to a developer and
makes the server more "portable"—in the sense it will be easier to change its deployment scheme if/when you'll need it.
Right to making it available to the Internet directly.
Conversely, with FastCGI, you'll always need a FastCGI host as a "middleware".
There were rumors that HTTP code is more fine-tuned in terms
of performance than that of FastCGI.
Still, this only will be of concern for reasonably hard-core loads.
One possible upside of FastCGI over HTTP is that it can
be served over pipes rather than TCP. For instance, you might
get it served over named pipes as it's supported by IIS's FastCGI module and there exists 3rd-party packages for Go implementing support for them
(even including one from Microsoft®).
The upside of this is that pipes are beleived to incur lesser overhead for data transfer (basically it's just shoveling bytes between in-kernel buffers belonging to two processes instead of pushing them through the whole TCP/IP stack), and using pipes frees you from the need of dedicating a TCP port to the Go server.
Still, I have no personal experience with this kind of setup and its performance trade-offs.
Excuse me. I speak poor English.
I am trying to create a network proxy programming with sock5 protocol. But I have no way to learn it, I can't figure out how a proxy programming works especially the followings:
What is the difference and association between socks5 and the Shadowsocks ?
Can I set a the network proxy configure in macOs instead of using swift or oc ?
such as enabling this check button(socks5 proxy) and filling the specific configure using a language instead of swift or oc:
configure
Once I set the option on macOs in the Question 2,what kind of data will the programming get if it listening the network?
e.g. will the macOs automatically forward the all new TCP connections to 127.0.0.1:1086 and automatically make the connections confirm to the socks5 request standard?
If so, why the final processing programming (transmit the datas to the real remote proxy-server) can make a successful connection? Instead of a forever loop(a.programming create a socket to remote proxy-server -> b. macOs automatically forward it to 127.0.0.1:1086 and make the connection confirm to the socks5 request standard -> a.)
Is it called as a proxy-client? or local proxy-server? what is the job of it. Why do I set a proxy address as a local one instead of a direct remote server?
Why when I setting a fake socks5 option in macOs network proxy options, a UDP programming can still work successfully?
If you can UNDERSTAND CHINESE:
Chinese language
The follow answers are based on my own experience and opinion.
1、socks5 is an Internet protocol that exchanges network packets between a client and server through a proxy server. Sockes
while Shadowsocks is a software use this protocol.
2 、Yes,you can. Install a Shaowsocks don't need any
Programming language, actually it like installing a EXE file on Windows or pkg on MacOS, it's just a software.
3、Socks5 is an Internet protocol like a language between two computer.
The software's message run on you computer will be "translated" by Shadowsocks.
Those translated message will be sent to the remote service (also run a Shadowsocks) then the service can send message to those "blocked" Webs' services.
4、The remote service can be called an proxy service.The local don't do anything except be "translated" by Shadowsocks. Look this picture.
5、The QQ don't use the port 1080, Shadowsocks need a fixed port to "translate" message.
I am having an incredibly difficult time finding any information by IBM on how to connect to our company's queue. Some more specific questions:
do I need the queue manage?
how do I know which queue connection factory to use?
how do I connect to the queue from a standalone java application?
I honestly can't find any MODERN, up-to-date resources explaining the websphere mq and how to make use of it (this includes within my own company).
Thanks!
You can connect to a queue manager in either binding mode or client mode. Binding mode allows an application to connect to the queue manager only when they are both running on the same machine. Client mode allows an application to connect to the queue manager when the two a running on separate machines. You can use client mode when they are both running on the same machine but its not as efficient as binding mode.
If you want to use binding mode then you only need to know the queue manager name.
If you want to use client mode then you will need to know the queue manager name, hostname, listener port number, and channel name.
The following URL provides some information on using JMS to connect to MQ:
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031500_.htm
Today I'm hosting a Laravel v4 web application on a MacMini. Why a Mac? Because I created the application logic in Objective-C (leveraging my experience with iOS dev). Whether or not this was the right choice isn't the point of the question.
What I'm interested in knowing is how can I separate my web and application server. For instance, if I put my web server on Linode (or whatever) how do I go about communicating back and forth between the web server and the application server? Is there some sort of resource I can look to to understand how to do this?
Assumptions
Here's some assumptions I'm making:
I'm guessing Laravel and the Objetive-C Application are part of the same "system" and so I'm just gonna treat this as if you need a web server to send requests to a PHP application.
The Linode server will be a web server which sends request to the PHP application (Laravel)
Hosting PHP Applications
There are three moving parts:
The web server (Apache, Nginx)
The application gateway (PHP-FPM)
The application
The gateway and the code must live on the same computer/server. The web server can live on a separate computer/server.
This means you'll need your Macintosh to run PHP-FPM, which can then listen for remote connects and send them to the PHP application.
Macintosh
Install php-fpm on your mac. Make sure it can listen for remote network connections. This is usually done in the www.conf file in the listen directory, you can listen for connections on the remote network interface (whatever IP address the computer is assigned).
Linode
Install Nginx or Apache and have it proxy FastCGI requests off to your macintosh server at the macintosh's IP address (the one you set up to listen to addresses in the step above).
Firewalls
You may need to ensure the firewalls at both ends allow incoming/outgoing connects on the networks being used to communicate to eachother.
It seems that both service and server refer to some web based application. But is there any precise definition of the two terms?
A server offers one or more services. Server is also a more technical term, whereas service is more a term off the problem domain.
You also need to distinguish between:
Server as hardware (see post from Dan D)
Server as software (eg. Apache HTTP server)
You can find more elaborate definiton on Wikipedia:
Service
Server
This is regardless of client-server or P2P models.
A server provides services to one or more clients, and a server(hardware) is a computer. A server(hardware) can be anything from a home computer to a big server-rack with a lot of processor power.
From the view of a computer, a server(software) is just a set of services which is available to clients on the network.
Some well known services are web-server, mail-server. ftp-server. notice they are called xxx-server because such programs consist of a client and server part. The postfix is mainly to distinguish whether we are talking about the client or the server.
So at what moment do we call something a server? We do it when a computer shares some service/content on the network, which is accessible by clients. In other words, when we make a server as defined for software.
Regarding the P2P model: every one is both a client and a server, hence called servent. The above apply to the server part of a P2P network, just remember that it also can be a client.
Futher reading:
Client-Server model
P2P
a server is a piece of hardware or on a virtual machine
a service is a process that provides services normally over the network and runs on a server
but a server can also refer to a web server which is actual a service but it's sort of like one as it hosts services
i think those are reasonable working definitions
I think a simpler way to define both besides the definition of the server being a piece of hardware, a server in the software sense is a service that serves data. In other words you interact with a server with a request and you should get a response back. It "serves" data.
A service does not need interaction and is pretty much just a random process that keeps running doing the same thing, but a server is a service because it is basically a process that keep waiting for a request to come in so that it can return a response.
"A service is a component that performs operations in the background without a user interface."
~ Android Developers
Services don't just run on servers
Shell services
Services can run from the shell. Unix refers to services as Daemons (pronounced "demons"), and Windows refers to them as services.
Client-side services
Services can run client-side. Mozilla (and other browsers) support Web Workers which run in a background thread. Client-side frameworks, like Angular, support services as well.