in a modern datacentre, it is said that after a physical server get plugged into the switch, then it can be discovered and then registered to the datacentre inventory system automatically without human intervention , and later one the system can be provisioned by a default os using pxe like technical, also automatically.
What is the common way of doing physical server auto discovery? The way I know a little bit is:
physical server management console(ILO)bootup automatically by querying IP address from the IDC dhcp server
-A management system sending broadcast ping to the whole network, any ip address which responses and has no record in the system is considered to be a new system.
management server connect to the server ILO using standard IPMI protocol and set the interface pxe configuration, then power cycle the server
When server boot up, a pxe installation is processed. server information can be registered to the inventory system during the installation procedure.
is there any other good way of doing this?
You are on the correct path if you are using the iLO. iLO supports LLDP discovery. An additional option will be to manage it from the iLO RESTful API that is also Redfish conformance.
SSDP is certainly very common and popular for this purpose outside the datacenter. An example of performing such discovery can be found here:
How can I list upnp server/renderer in command line (console mode) on linux?
Which uses the gssdp-discover utility.
Redfish standard, which all major vendors support, specifies the
gssdp-discover -i eth0 --timeout=3 --target=urn:dmtf-org:service:redfish-rest:1
Ana- HPE Employee
Related
I have set up a LAMP server on a Raspberry Pi on my home network. I would like to expose the pi to the internet by opening up ports 22 and 80 on my router so i can ssh into it as well as use any web services i set up on it.
This is a little pet project I'm using to learn more about networking, server setup and linux in general - with only a cheap RPi which i can wipe and start again easily anything goes wrong. I do plan to put it on a separate subnet to the other devices on the home network, just in case.
(Yes, i know this is a little much for a raspberry pi - this is just a learning exercise and a proof of concept before i throw money at this to build a rig for it)
My understanding is that SSH is already secure, so i don't have to worry about my username and password being seen across the web when i want a terminal session.
My concern is that if i send anything to a web service (such as a wordpress or phpmyadmin password) it'll be clear to see on the web. How can i stop this?
My plan was SSL, but from what I've read, an SSL certificate needs a domain name for a certificate to be issued by most places. When all I'll be doing is pointing to a static IP from my ISP on the devices I'll be using.
The other use i have planned for it is as a mysql server for my kodi boxes to use for the library data so my devices can share data (the videos live on another server running windows). So other devices on a local network need to be allowed access to mysql easily without the silly level of security the internet-side requires. I assume this will be easily possable alongside my other use cases as I'd not be opening the port for it on the router and the only things that would access msql are local network devices, and services on the mysql host itself
Are any of my assumptions or conclusions wrong?
Are there any better ways to achieve what I'm after than what I'm describing?
Is there a preferred way to interact with the Pi if i just wanted it to set off a specific script? (say send a wake-on-lan packet to a specific computer)
Is there a way for me to have the web server onllly communicate with specific devices that i have the appropriate keys/certificates loaded onto so that i can be certain that I'm the only one with access?
Are any of my assumptions or conclusions wrong?
Using a username/password combo for SSH is probably secure enough, but it's generally more secure to use a public/private SSH key pair.
Your assumptions about MySQL seem sound. Just make sure to have some authentication on the server just in case you have a nosey houseguest on your WiFi. :)
Are there any better ways to achieve what I'm after than what I'm
describing?
A couple options that come to mind:
You could generate a self-signed certificate for the web server and then manually copy that onto your client devices. I think this would allow you to get around the requirement for a domain name.
You could set up a secure VPN into your home network. This way you wouldn't have to expose your web/SSH servers to the world.
Is there a way for me to have the web server only communicate with
specific devices that i have the appropriate keys/certificates loaded
onto so that i can be certain that I'm the only one with access?
The VPN option mentioned earlier would allow you to do this.
You could restrict access to the Apache server to only devices with specific client certificates: https://stackoverflow.com/a/24543642/2384183
So, we all use TeamViewer for accessing GUI based (Windows / Linux) remotely and of course, it works really well.
Any ideas of how to do the same with headless (Ubuntu) servers? I'm thinking that the headless servers would run some sort of service that connects to a central server, which I can then remote into (somehow) and then route through the central server to the remote server.
It's kinda like the server based TightVNC that was popular a view years ago, where you could host the "server" module and have all your TightVNC clients connect to that server, whilst you do the same on your client, and the server module provides a gateway through to the remote systems. Just like TeamViewer really.
I wonder if the remote servers can connect to the (central) gateway server via SSH, I would do the same (again via SSH) but then the gateway server will provide me a "tunnel" through to the remote server.
I would of course prefer to have the remote servers have SSH ports opened through their firewall and then connect to them directly, but sometimes their IT teams don't like that. Having a server that runs a service, connects to a public server, means that the IT team will typically permit this, as the traffic is initiated internally and would be even more so agreeable to permitting it if that traffic uses an encrypted protocol.
Anyway - I just wondered if there was something out there that I could have a look at and see if it would work??
If you don't want a cloud controlled service (with serious security issues as of late), then check out the self-hostable MeshCentral project. It creates outbound tunnels that allow devices to communicate behind NAT and other networks.
Good news! Teamviewer 11 supports headless Linux servers :)
https://www.teamviewer.com/en/help/1111-How-do-I-install-TeamViewer-on-a-Linux-system-with-no-graphical-user-interface
Try https://www.dwservice.net/en/
Works on RPI, Linux and Windows.Best Part is free and Support for Terminal access
not just GUI ( so works faster in slower internet ) .
Client side- > just run the script ( not need of GUI)
Remote side - > Run just browser.
does anybody know an API that allows to send and receive data to/from a VMWare guest system without using an IP network?
I have to communicate with a program inside a VMWare guest but the guest is not allowed to have an IP network. As file transfers into the VM via Drag&Drop are possible I assume that there is an API - I just need to know if this API is open to 3rd party programmers or if it is only available fro the VMWare Player itself.
Sure, you can access those with the VIX API.
More specificely, the Drag&Drop is implemented with following functions:
VixVM_CopyFileFromGuestToHost
VixVM_CopyFileFromHostoGuest
Basically all VixVM functions may be relevant for your tasks. They are all documented in the official VIX API reference.
It turns out that there is a solution for my problem:
Virtual Serial Port
VM-Ware allows to create virtual serial ports for the guest that are connected on host side to a named pipe.
I therefore created two helper programs, one on host side which listens on a TCP port and a specific named pipe and transfers all the incoming data between them.
A second helper program runs in the guest VM and does the same between the serial port and the TCP port I want to access.
The only draw-back is that the serial speed is limited to 128kBit/sec. May be that can be increased by using multiple virtual serial ports...
Virtual Machine Communication Interface (VMCI)
Using VMCI there is an API for creating a shared memory region that is accessible from both hast and guest system.
I have several smart devices that run Windows CE5 with our application written in .NETCF 3.5. The smart devices are connected to the internet with integrated GPRS modems. My clients would like a remote support option but VNC and similar tools doesn't seem to be able to do the job. I found several issues with VNC to get it to work. First it has severe performance issues when ran on the smart device. The second issue is that the internet provider has a firewall that blocks all incoming requests if they didn't originate from the smart device itself. Therefore I cannot initiate a remote desktop session with the smart devices since the request didn't originate from the smart device.
We could get our own APN however they are too expensive and the monthly cost is too great for the amount of smart devices we have deployed. It's more economical for us if we could add development costs to the initial product cost because our customers dislike high monthly costs and rather pay a large sum up front instead. A remote support solution would also allow us to minimize our onsite support.
That's why we more or less decided to roll our own remote desktop solution. We have code for capturing images on the smart device and only get the data that has changed since the last cycle. What we need is to make a communication solution like logmein.com (doesn't support WinCE5) where the smart devices connect to a server from which we then can stream the data to our support personnel's clients. Basically the smart device initiates a connection to our server and start delivering screen data when the server requests it. A support client connects to the server and gets a list of available streams and then select one to listen in on.
Any suggestions for how to do it considering we have to do the solution in .NETCF 3.5 on the smart devices? We have limited communication experience beyond simple soap web-services.
Since you're asking for a suggestion, I'll suggest this:
Don't reinvent. Reuse whatever you can. You can perform tunneling with SSH, so make an SSH connection (say, a port of PuTTY or plink, inside a loop) out via GPRS on your smart device; forward remote ports to local ports, bound to the SSH server's local address (127.0.0.1 (sshd):4567 => localhost (smart_device_01):4567). Your clients connect to your SSH server and access the assigned port for each device.
With that said, that's probably not the answer you're looking for. Below - the answer you're probably looking for.
Based on my analysis of how LogMeIn works, you'll want to make an HTTPS or TLS server where your smart devices will push data. Let's call it your tunnel server.
You'll probably want to spawn a new thread that repeatedly attempts to make connections to the tunnel server (outbound connections from smart device to the server, per your specified requirement). With a protocol like BEEP/BXXP, you can encapsulate and multiplex message-oriented or stream-oriented sessions. Wrap BXXP/BEEP into TLS, and tunnel through to your tunnel server. BEEP lets you multiplex streams onto one connection -- if you want the full capabilities of an in-house LogMeIn solution, you'll want to use something like this.
Once a connection is established, make a new BEEP session. With the new session, tell the tunnel server your system identification information (device name, device authentication signature). Write heartbeat data (timestamp periodically) into this new session.
Set up a callback (or another thread) which interfaces to your BEEP control session. Watch for a message requesting service. When such a request comes in, spawn the required threads to copy data from your custom remote-display protocol and push this data back through the same channel.
This sets the basic premise for your Smart Device's program. You can add functionality to this as you desire, say, to match what LMI's IT Reach subscription provides (remote registry, secure tunneled Telnet, remote filesystem, remote printing, remote sound... you get the idea)
I'll make some assumptions that you know how to properly secure all this stuff for authentication and authorization for your clients (Is user foo allowed to access smart device bar?).
On your tunnel server, start a server socket (listening for inbound connections, or from the perspective of smart devices, smart device outbound connections) that demultiplexes connections and sessions. Once a connection is opened, fire up BEEP and register a callback / start a thread to wait for the authentication/heartbeat session. Perform the required checks for AAA to smart devices -- are these devices allowed, are they known, how much does it cost, etc. Your tunnel server forwards data on behalf of your smart devices. For each BEEP session, attach a name (device name) to the BEEP session after the AAA procedures succeed; on failure, close the connection and let the AAA mechanism know (to block attackers). Your tunnel server should also set up what's required for interacting with the frontend -- that is, it should have the code to interact with BEEP to demultiplex the stream for your remote display data.
On your frontend server (can be the same box as the tunnel server), install the routine for AAA -- check if the user is known, if the user is allowed, how much the user should be charged, etc. Once all the checks are passed, make a secured connection from the frontend server to tunnel server. Get the device names that the tunnel server knows that the user is allowed to access. At this point, you should be able to get a "plaintext" stream, based on the device name, from the tunnel server. Forward this stream back to the user (via TLS, for example, or again via BEEP over TLS), or send the required configuration for your remote display client to connect to your tunnel server with the required parameters to access the remote display protocol's stream.
Similar to the Visual Studio development web server (Cassini) limitation that it only servers on localhost, I have a WCF Service implementation that is only needed on localhost.
I wouldn't mind other machines having access, except that the Windows Firewall prompts to allow the program to listen on the externally-facing NIC. Since this is only needed internally, I would rather restrict the WCF Server-side configuration so that it doesn't trip the firewall detector.
Is binding.HostNameComparisonMode = HostNameComparisonMode.Exact the right solution? I don't see how this is enough.
====
Like Cassini, this Service implementation is a stand-in for something else which DOES require network communication. The client can be configured to connect to the real server or the fake implementation running on localhost.
I think that you are approaching it the wrong way. You should be using the named pipe binding, which should support whatever message exchange pattern you are using (it supports request-response, as well as the same concurrency and session state modes that WS supports).
From the section of MSDN titled "Choosing a Transport" (emphasis mine):
When to Use the Named Pipe Transport
A named pipe is an object in the
Windows operating system kernel, such
as a section of shared memory that
processes can use for communication. A
named pipe has a name, and can be used
for one-way or duplex communication
between processes on a single machine.
When communication is required between different WCF applications on
a single computer, and you want to
prevent any communication from another
machine, then use the named pipes
transport. An additional restriction
is that processes running from Windows
Remote Desktop may be restricted to
the same Windows Remote Desktop
session unless they have elevated
privileges.
This satisfies your exact requirements and should be no more than a configuration change.
It depends on how you are hosting it. If you are in IIS7 or WAS, then WCF uses IIS's mode of matching. Otherwise, if you use HostNameComparisonMode.Exact, then yes, the host name will always be a critical factor in matching. If the host name does not match, dispatch will generally fail.
It should be noted that exact is not 100% perfectly exact...it still allows some variation in the host name. If you have both a NetBios host name and a full DNS name, matching will still occur, as WCF treats those two as one and the same.
System.ServiceModel.BasicHttpBinding.HostNameComparisonmode