Is there a difference between using salt-proxy ssh and directly salt-ssh? I'm interested because according to documentation both aimed to run remote commands without agent installation on the end machine.
You cant simply do salt-ssh on a proxy minion, for which you would have to write your own custom ssh interface to the remote system, because your proxy minion may not support doing salt-ssh.
How to choose between using salt-ssh vs salt-proxy totally depends on the type of a minion system.
As stated in the saltstack documentation - https://docs.saltstack.com/en/latest/topics/ssh/index.html and
https://docs.saltstack.com/en/latest/topics/proxyminion/index.html
For salt-ssh to be used, the remote system must have python installed - one of the criteria. For example, controlling ubuntu from centos.
As stated in the salt-proxy doc,
Proxy minions are a developing Salt feature that enables controlling
devices that, for whatever reason, cannot run a standard salt-minion.
Examples include network gear that has an API but runs a proprietary
OS, devices with limited CPU or memory, or devices that could run a
minion, but for security reasons, will not.
Related
I'm new to the WSL2 and wondering if it's possible to run the same WSL2 ubuntu instance on both my desktop and laptop.
Now I am able to use wsl --export and wsl --import method to save and load the system to/from my portable hard drive. But these methods takes a long time.
I notice that wsl --import load a file named ext4.vhdx. Is there a way to load straightly from this file?
Update v2.0:
I was able to get a workaround and it works great.
Thanks to Booting from vhdx here, I was able to load straightly from my vhdx file on my portable hard disk. Windows track down its subsystem with regedit, So we can write our own(p.s: make sure to get BasePath right, it starts with "\\\\?", or you will not be able to access the subsystem' filesystem on your host system.):
Windows Registry Editor Version 5.00
[HKEY_USERS\【your SID here】\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{【UUID here】}]
"State"=dword:00000001
"DistributionName"="distribution name"
"Version"=dword:00000002
"BasePath"="vhdx folder path" 【 e.g. "\\\\?\\E:\\S061\\WSL\\ubuntu-20"】
"Flags"=dword:0000000f
"DefaultUid"=dword:000003e8
I suppose the best way to do this would be to store ext4.vhd on a network storage device accessible to both devices.
I have previosly mentioned how to move ext4.vhd. You can check that out here
Basically you need to export from one machine and import it while making sure the vhd file is configured for wsl to access from the network storage
Since this should *officially* not supported expect some performance hits
Another way would be to run WSL on one computer and ssh/remote desktop to it from another device on the network
I'm of the strong belief that sharing the same ext4 vhd between two VM's simultaneously would be a bad idea. See this and this Unix & Linux StackExchange, including the part about ...
note that sharing LVs/partitions on a single disk between the servers at the same time is NOT very safe. You should only access whole disks from any of the servers at one time.
However, as dopewind's answer mentioned, you can access the WSL instance on one computer (probably the desktop) from another (e.g. the laptop). There are several techniques you can use:
If you have Windows 10 Professional or Enterprise on one of the computers, you can enable Remote Desktop, which allows you to access pretty much everything on one computer from another. RDP ("Remote Desktop Protocol") even works from other devices such as an iPad or Android tablet (or even a phone, although that's a bit of a small screen for a "desktop"). That said, there are better, more idiomatic solutions for WSL ...
You could enable SSH server on the Windows 10 computer with the WSL instance (instructions). This may sound counterintuitive to some people, since Linux itself running in the WSL instance also includes an SSH server (by default). But by SSH'ing from (for example) your laptop into your desktop's Windows 10, you can then launch any WSL instance you have installed (if you choose to install more than one) via wsl -d <distroName>. You also avoid a lot of the network unpleasantness in the next option ...
You could, as mentioned above, enable SSH on the WSL instance (usually something like sudo service ssh start) and then ssh directly into it. However, note that WSL2 instances are NAT'd, so there's a whole lot more hackery that you have to do to get access to the network interface. There's a whole huge thread on the WSL Github about it. Personally, I'd recommend the "Windows SSH Server" option mentioned about to start out with, then you can worry about direct SSH access later if you need it.
Side note: Even though I have SSH enabled on my WSL instances, I still use Windows SSH to proxy to them, to avoid these networking issues.
I have what I believe to be a very simple question.
Context
I have a Raspberry Pi Zero W running Raspbian Lite (2020-02-13-raspbian-buster-lite.img).
Question
How do I change just one file on the SD Card, e.g. in the host partition, to auto-configure the raspberrypi as a wifi hostpot, and call it raspberrypi.
Also, I would like to be able to set the hotspot to be open, or with a password raspberry (just like the ssh password :) ).
What I tried already
I found lots of instructions on installing software packages, but unless I'm connecting via ssh already, then I can't run commands unless I'm already networked to the pi.
Why do I want this?
I want to be able to do this, for much greater ease of connecting to a raspberrypi in the first instance, for example, along with enabling ssh, this would allow very simple ease of access for incoming connections.
Only an idea
Finally, what does anyone think of the idea of enabling this by default in Raspbian. It can be disabled is required, but would substantially ease the process of connecting to a Pi with a Raspbian image out of the box - allowing a use to see so-called "proof-of-pi" immediately after first boot.
As far as I've seen, configuring the Pi before-first-boot by editing the boot partition files is limited. However there are some custom tools out there where you can look at creating a custom image or design some provisioning steps for your Pi.
PiBakery is a tool for creating custom images of Raspbian. Setting up a WiFi hotspot will most certainly require a custom script for tool installation and configuration.
I know that you can configure a SD card to auto-connect to WiFi (for normal network connections) by creating a wpa_supplicant.conf file and setting some values in boot's config.txt, you may want to check some of the documentation from the Raspbian project regarding config.txt. Keep in mind that the default raspberrypi.org image is slightly different than the Raspbian Project's image, so your mileage may vary.
Finally, depending on your use case for this/deployment strategy, you can also look into changing the Pi's boot mode so that it boots from a network host, kind of like "PXE Boot" for Windows machines. You'd have to host a provisioning server that the Pi can get information from and sync up with, which may be out of the bounds of what you're trying to accomplish, but I figured I'd bring it up!
Setup:
I have a setup with several ESXi 5.5 hypervisors (paid licenses) and a vCenter 6.0 linux server instance. I don't have any other infrastructure like vCloud, workstation, etc. I'm using ovftool to deploy a VM from an OVF template. The template that I deploy has no IP configuration when it starts up.
What I'm trying to do:
Automatically configure a static IP address, mask, and gateway through some scripted means. I haven't found a feasible way to do this with ovftool itself.
Requirements:
It cannot use DHCP. This infrastructure is not set up in our network and it is not feasible to do so.
It must be run in a remote Linux machine, within the command line of the hypervisor, or within the command line of vCenter.
It must be a production supported approach (no hacks).
Besides that, I don't really care what language is used to do it. Something ordinary like bash, python, c, java, perl, etc is preferable over something obscure.
If an interface is mentioned (like an API), please note the specific functions that can carry out this operation rather than just saying "oh this interface can/should be able to do that".
Is there an established way to take a Vagrant box and use it as the operating system for a "bare metal" machine, i.e. a normal computer and not a hypervisor, without having to sit through an installation process?
Now I understand the common response will probably be "install an OS regularly and then use a proper configuration management tool like Puppet or Chef" but hear me out. Our IT organization would like to create a base Vagrant box with all security-related protocols and applications enforced. Then a configuration management tool like Puppet could install "useful" applications like databases and web servers on top of it.
This works best when a software developer wants to deploy a new utility to development environments or servers - they can write the Puppet code to install exactly what they want, which can be turned over to IT to run it on top of the validated Vagrant box to create a virtual machine server.
By hosting the Vagrant box internally, we can hide the security details from the developer while they write new Puppet code, they can test their Puppet code on the same environment they will run it on, and it will provision much faster during testing since the box is just downloaded once. Most "production" deployments will stay as Virtual Machines.
In rare circumstances, we may want a real, bare-metal server, not a VM, probably when we get new hardware to run more VMs or if the utility we need is very computationally intensive. It would be nice if the existing Vagrant box could be repurposed so bare-metal and virtual servers were indistinguishable.
EDIT: I found a post on askubuntu (https://askubuntu.com/questions/32499/migrate-from-a-virtual-machine-vm-to-a-physical-system) which seems to do what I want, can anyone verify if such a procedure would work on a Vagrant disk image, if there would be necessary cleanup (like Vagrant ssh keys) or if it could be generalized to non-Ubuntu operating systems (since it uses Live CD)?
A Vagrant box packaged for VirtualBox is essentially a virtual disk with metadata. Most likely it's going to have the VirtualBox tools and drivers installed, which won't do much good on a physical system. Not only that, the drivers for the physical system would need to be installed on the box image.
What you're talking about doing is a good use case for some sort of "ghosting" software that simply copies blocks of data to a physical disk. There's really no advantage to using Vagrant here that I can see.
We wrote a small prototype web app using Pharo and Seaside and we want to now demonstrate to the suits that the app can be deployed into our standard Linux build. We use a mix of CentOS, Ubuntu Server and Gentoo which are run headless since most of our apps are JAVA/Apache based. Only port 80 and 443 are open to the outside world.
What are your experiences when hosting Seaside/Smalltalk server side apps?
it runs great, btw you can get free hosting for your seaside app at:
http://www.seasidehosting.st/
for more power you'd need your own server of course...
some benchmarks here:
http://gemstonesoup.wordpress.com/2007/10/19/scaling-seaside-with-gemstones/
The Seaside Book has a chapter on deployment. It describes how I typically deploy a Seaside application.
I just use a ssh tunnel to get the X display on my local machine. I'm using slicehost (US) from the Netherlands, so I have a ping time of 135 ms. That's not that nice, but ok.
Next step will be Lukas Renggli's remote frame buffer package to use a vnc viewer.
Let's see what Miguel Cobá had to say about it on it on the Gemstone mailing list:
If you have already installed a RFB in your machine then use it.
If you have RFB installed in your image and it is accesible from your
client machine, use it
But, both of them are unencrypted. If you want to encrypted you must
setup a tunnel (maybe with ssh or maybe TLS).
I think that that is redundant because you must use a tunnel and then
the RFB. So what I do, in linux is to install the minimal X libraries
and then forward the X session to my local machine.
In the server (Debian/Ubuntu instructions):
aptitude update
aptitude install xbase-clients
aptitude install xtightvncviewer
Test it from the client machine:
ssh -X remote_server
squeakvm gemtools.image &
This will start the squeakvm process on the server, but all the graphics
will be shown on the local machine (the Xserver for this particular
scenario).
Also, if you install RFB on some of your images and start them headless,
you can use xtightvncviewer to connect to inside the image through the
RFB server.
ssh -X remote_server
xtightvncviewer localhost:0 &
this will run the xtightvncviewer on the remote server but, again, will
show on your local machine. Supposing you have your image in the remote
server running RFB in the first display.
Which is the advantage:
- You don't have to open ports for RFB on the remote server
- You transmit everything encrypted through ssh
- You only run the commands on demand in the remote server. You don't
have to have VNC running always.
- You can configure your RFB in the image to accept only localhost
connections and not from everywhere.
Martin McClure adviced me to take a look at NoMachines NX (less chatty X),
but that's still on my todo list.
For another set of deployment instructions, take a look at Miguels blog
The blogosphere's been talking about this issue recently.
Doug Putnam wrote up his experiences in installing Seaside (on Pharo) on his Slicehost slice, working off James Robertson's writeup (which uses VisualWorks, I suppose?).