There are two types of remote extensions as you see in the pictures. The ones in blue and the ones in green that are tagged with nightly at the end. They are both developed by microsoft and I can't see any difference between the two Remote - SSH extensions.
What is their difference?
Remote - SSH is the stable version and the Remote - SSH (Nightly) is the "nightly" build, meaning it contains the newest features that are not considered stable yet.
Actually, the build/release doesn't seem to be strictly nightly, but nightly is generally used to mean the latest and greatest.
Related
I have two Linux machines from which I make ssh connections to different hosts however I find that the client versions on these two Linux machines are OpenSSH_7.6 and OpenSSH_7.6p1. I tried to look up the differences between these two versions at https://www.openssh.com/releasenotes.html but it seems they are same version.
I would like to understand what is the difference in these two versions if any and why such nomenclature strategy.
not very difference but in 7.7p1 its change
you can check this diff in https://fossies.org/diffs/openssh/7.6p1_vs_7.7p1/
or check all change log commit in here https://fossies.org/diffs/openssh/7.6p1_vs_7.7p1/ChangeLog-diff.html
As found on https://www.openssh.com/portable.html
The portable OpenSSH follows development of the official version, but releases are not synchronized. Portable releases are marked with a 'p' (e.g. 4.0p1). The official OpenBSD source will never use the 'p' suffix, but will instead increment the version number when they hit 'stable spots' in their development.
We develop a server-side solution and to ease its deployment we would like to provide our cutomers with two options:
1. Docker image
2. VM image in OVA format
The images should be automatically created by our build machine.
As of today, we use packer for this purpose. First we create docker image and then update that image in preconfigured virtual machine image (using 'virtualbox-ovf' builder). This works pretty well, but there are some problems with this solution.
First, our vm includes docker framework and two OSes (host's and docker's), so our VM image is ~twice bigger than docker. Second, to base our solution on another linux distro, we should manually configure new VM machine.
We are looking for 'Dockerfile'-style solution to create and configure VM automatically and then export it in OVA format. 'virtualbox-iso' builder is the obvious way to do this, but the building process will be much longer.
If you are willing to use Debian as your base OS then you could look at TurnKey Linux's TKLDev. It's probably a bit of a learning curve initially but it's a pretty cool thing IMO (although I'm very biased - see below disclaimer). TKLDev will build you a TurnKey (Debian based) ISO with your software installed on top. Then using Buildtasks you can convert the ISO to OVA, VMDK, LXC, Docker, OpenStack, etc...
Unfortunately Buildtasks is not very well documented but significant chunks of it are in bash so if you are handy with a Linux commandline you could work it out. Otherwise ask on the TurnKey forums.
The initial development (from Packer to TKLDev) may take a little while, but once the heavy lifting is done the creation of an ISO (in a guest VM on a moderm multicore CPU PC) takes about 10-15 mins and the OVA probably another ~5; Docker another ~5.
If you wanted to make it build automatically then you could use a hook to trigger a fresh TKLDev build (including the buildtasks image creation) everytime a commit was made to a repo. I know that git supports this but I assume that other version control systems allow something similar.
Also if the appliance that you are making is open source then perhaps it could be added to the TurnKey Linux library?
Disclaimer: I work with TurnKey Linux. :)
FWIW this is essentially the process we use to create our library of appliances in most virtualisation formats known to human kind!
I need to do integration testing for a spring cloud application running with spring data on redis.
Tests work locally with the regular redis server instance and I need to run this on a Jenkins CI server that is controlled by the corporate CI engineering group.
Obviously I can attach to a redo server there so I used an embedded redis server (from here: https://github.com/kstyrc/embedded-redis).
Running tests locally with this redis server works well since there is a test profile to inject the embedded server in place of the production one.
Now the problem is that when we run this in the Jenkins environment this is the error we see.
/tmp/1430170830037-0/redis-server-2.8.19: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/1430170830037-0/redis-server-2.8.19)
So this version of redis has specific dependency on a specific version of glibc. I tried a couple of other libraries but they all depend on the same underlying version of the embedded redis server.
Is there a spring data mock framework that can be used to get around this sort of issue?
This might come a little late for you, but there is indeed a Spring Data Mock framework that you can use, which let's you mock repositories (regardless of the specific backend solution) without a real database connection.
Here is a link: https://github.com/mmnaseri/spring-data-mock
You don't have a high enough version of libc6, that is causing the error.
From How to fix “/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found”? – Super User:
That means the program was compiled against glibc version 2.14, and it requires that version to run, but your system has an older version installed. You'll need to either recompile the program against the version of glibc that's on your system, or install a newer version of glibc (the "libc6" package in Debian).
So, you just need to upgrade your libc6 package. All versions of Ubuntu have at least version 2.15 because it's a faily important package (reference).
To upgrade it, use these commands in a terminal:
sudo apt-get update
sudo apt-get install libc6
p.s. This is answer from askubuntu.com by minerz029
I am trying to two-way sync my NAS (running Lubuntu) from my local network to a remote server (running Debian) with Unison CLI. I was using Unison before syncing my laptops files directly with the remote server. I always get an issue when trying to sync files from my NAS to my server:
Invalid argument: index out of bounds
Does anybody know why this happens? Is there a problem because Debian and Ubuntu are using not the exactly same version of Unison?
Edit: So in addition to making sure the Unison version numbers match and that the same version of OCaml was used to compile (as I said in my original answer below), there is one more thing necessary to get Unison working on your Banana Pi: compile it into bytecode, not native code. It turns out that (for whatever reason) Unison doesn't compile properly into native code for ARM processors like what the Banana (and my Raspberry) Pi have.
If you download a pre-compiled version of Unison it should work fine, but if you compile yourself, be sure to add the line Native=false to the Unison Makefile.
According to the unison manual:
It is important that the version of Unison installed on the server machine is the same as the version of Unison on the client machine.
This is because they change the format of the archive file in practically every update. You can check your version with unison -version. Update unison (or build/install it from source) to ensure your versions match, and then edit your post if you still have the same problem.
In some cases it also turns out to be important that unison is built using the same version of OCaml. I'm using Unison version 2.40.63 and I've had to build using OCaml 3.12.1 to avoid issues.
Is is possible to automate the installation of an OS using VMware or any other virtualization product?
One of our products consists of a customized version of CentOS that installs the OS and our application on a server. It's much like any CentOS/RHEL installation where you choose a mode that corresponds to different kickstart options, and then you choose your keyboard type. The rest of the installation is automatic.
What I'd like to have is an automated system that will create a new guest VM, boot it with the ISO image of our product, start the installation (including choosing the keyboard), wait for the reboot, and then launch a set of automated tests.
I know that there are plenty of ways to automate the creation of new VM guests from existing templates/images, and I know you can use the VIX API to interact with virtual machines, but the VIX API seems to require that VMware tools is already running (which won't be the case when you're booting from the CentOS install disk).
This answer (Automating VMWare or VirtualPC) indicates that you can script VMware to boot from an ISO that does an unattended installation, but I would really like to test the same process that our customers will be using.
Another option might be to use Xen's fully-virtualized mode and see if scripting it over the serial port will work.
TIA,
Jason
I have a very very similar question, it is on superuser:
https://superuser.com/questions/36047/moving-vmware-os-image-as-primary-os-on-a-system
You can also use VirtualBox instead of VMWare. The VirtualBox SDK allows you to directly control the keyboard, the mouse the serial port and the parallel port of the guest without the virtualbox guest tools installed.
Unfortunately it doesn't offer a text console interface but the serial port can be connected to a local pipe file and that can probably be worked with just as well.
This may not be exactly what you need:
I have done something similar with a Ubuntu-based install. We used preseeding (Debian's form of kickstart), to answer all the questions during the install - providing the preseed file and the installer via tftp.
In addition to the official Ubuntu mirror we added the apt-server with our own packages in the preseed file. We put a .deb version of vmware-tools on the apt-server and added it to the packages to be installed.
The .deb of vmware tools just contained the .tar.gz and a postinstall script that would extract it to /tmp and run the vmware install script (which has a switch to be run unnattended, so it does not ask any questions).
So after the reboot vmware-tools were up and running and we could use vix to script the rest (which was not very reliable).
If you should encounter problems with running vmware-config.pl during boot, you could make a custom package that just extracts the tools and an init script that installs them on first boot, disables itself and reboots.
Maybe you can use this strategy (replacing apt by yum, preseed by kickstart and tftp by a remastered iso). If you really need to test that your users choose a keyboard in the installer (which is not very different from kickstart) this would obviously not work for you..