Linux

VS2017RC Tooling on Linux

What better way to try out VS2017 RC, by creating a .Net Core solution on windows, and building it on linux.

However the standard .Net core installation guide for Linux, as of the date of this post, will not build VS2017 RC projects, due to it utilising *.csproj files, and no longer creating xproj / project.json files.

Expect an error along the lines of:

A version check will show that the "latest" is quite on the bleeding edge as it needs to be.

Compare this to Powershell after a VS2017 .Net Core install in the windows box.

Initially, the only option looked to be building from the preview branch in git.

However, there is a series of preview binaries available for those looking to hit the ground running faster.

https://github.com/dotnet/core/blob/master/release-notes/preview3-download.md

Howover, that is waye tyopo easy.

Building the .Net CLI in Linux

Let's build us the .Net CLI.

After a git clone, switch to the preview 3 branch.

Initally, it's going to take a while, the bash that kicks it all off is  /build.sh

The scripts go three to four deep ,at least. Adding a set -x to the top level script next to the existing set -e will give us some visibility into how the build is going.

Post Build

Once built set up a new symlink. As it will be to the same executable, dotnet, create it in a subfolder to /user/local/bin, and then remove it, and remove the folder.

You can then have a stable binary, and a build version running side by side.

Troubleshooting

One nasty looking error I bumped into was this one, in red, making it extra ominous.

Let see, its mention Net 4.0, and a GAC< on a LInux bo-x that is running .Net Core.

Not looking good. There are no .Net 4.0 References in the project and the whole point of .Net Core is to stand alone with a dependency on Mono. As for the GAC reference, this message doesn't give is much to go on.

Until you realise all you need to do is restore the project.

It does show that while the base cross-platform functionality is there, removing the legacy windows reference is going to be some time away for this fledgeling framework.

 

While chrome developer tools allow you to test for many http post vulnerabilities relating to invalid post data, testing for a slow post vulnerability needs Googles slowhttptest tool.
https://github.com/shekyan/slowhttptest

The installation in very straight forward
https://code.google.com/p/slowhttptest/wiki/InstallationAndUsage

As the docs say, you'll need lib-ssldev. When missing you'll get:

My LMDE does not have this out of the box, though Synaptic delivered.

 

After the make, running slowhttptest hits up localhost by default. Nothing interesting without a local test server.

Shekyan also includes the syntax to launch an example of the SLOWORIS attach to test on your own servers.

 

With the success on preliminary benchmark on my use case for Elasticsearch . I thought I would see how it ran on a ARM based ODroid U3.

The U3 is a credit card sized mini PC from HardKernel, that runs Android or Linux.

The Odroid U3 Specs include a 1.7GHz Exynos4412 Prime Cortex-A9 Quad-core processor, and 2GB RAM. While it support MMC storage, I'll be using a 16GB Sandisk Ultra UHS I Class 10 SD Card, in part to makes things interesting, and in part so I easily swap out my Android XBMC MMC between projects.

I have gone with Ubuntu 14.4 from the ODroid forum site.

Oracle Java 8 via apt-get was straight forward, however elasticsearch via packages.elasticsearch.org did not explicitly support armhf.

I added the following to /etc/apt/sources.list as outline by the docs

However apt-get update gave me the following error.

As Elasticsearch runs in Java, I figured running the x86 version would be fine. Just needed to figure out how to do it.

After hitting a dead end after editing /etc/dpkg/dpkg.cfg.d/architectures, I tried adding architecture tags to /etc/apt/sources.list as outlined in the Multarch/HOWTO.

Worked a treat, package sources updated, and elastic search installed as a deb package.

After finding that the node.js PM2 plugin was only supported in linux, I had a reason to dust off my LMDE VM.

When building CynanogenMod ROMs for my HardKernel ODroidU2, I quickly outgrew Ubuntu, which I choose due to the huge amount of community support, and the references to it specifically in various Android ROM building getting started documentation.

Linux Mint was next, though I soon after settled on Linux Mint Debian Edition to make advance of the rolling releases, perfect for a tertiary VM. I could jump in after it being offline for months at a time, and be on the latest version after tackling the backlog of updates, as opposed to having to rebuild, being the recommended upgrade path of various other distros.

The customised Mint-X theme with Buuf 3.6 Icons reminded me how much time i had setting up this VM. This included creating a custom Gnome Desktop Manager page based off RastaGrrl's GDM Theme by hand with Pluma for the XML and Gimp for the Icons.

Buuf ThemeLogin

GParted was still attached to the Virtual CD Rom, for when I had to expand the partition, for the second time, as I couldn't bring myself to start from scratch after I underestimated the local storage needed to build one, and them multiple ROM branches from scratch.

LMDE just seems to be built by Devs for Devs, with none of the irritants that drove me away from Ubuntu, which when incurring frustration seemed to be the perfect example of the camel the committee inadvertently designed. From the Granted permissions without asking for password dialog to the lack of OS branded services trying to be pushed onto me. (Looking at you Ubuntu One,), it just felt like home, even if some of the flashier desktops were not available in debian packages.

While the update from LMDE 1.0.6 to 1.0.9 was a few hundred K, the 1081 recommended updates coming in at 788 Meg showed that maybe it was a bit too long between visits.

Looks like my experimentation with node.js under linux may have to wait till tomorrow.