Home Blog Page 496

Microsoft Wants to Make Blockchain Networks Enterprise-Ready With Its New Coco Framework

Interest in blockchains is at an all-time high, but there are still plenty of technical issues to solve, especially for enterprises that want to adopt this technology for smart contracts and other use cases. For them, issues like throughput, latency, governance and confidentiality are still major stumbling blocks for using blockchains. With its new Coco Framework, Microsoft wants to solve these issues and make blockchains more suitable for the enterprise.

In an interview earlier this week, Microsoft’s CTO for Azure (and occasional novelist) Mark Russinovich told me the company is seeing a lot of interest in blockchain technology among its users. They like the general idea of a distributed ledger, but a system that can only handle a handful of transactions a second doesn’t work for them — what they want is a technology that can handle a thousand or more transactions per second.

The Coco Framework solves these fundamental issues with blockchains by introducing a trusted execution environment (TEE). 

Read more at TechCrunch

How Captive Portals Interfere With Wireless Security and Privacy

If you have ever wanted to use the wifi at a coffee shop or library, you have probably had to click through a screen to do it. This screen might have shown you the network’s Terms of Service and prompted you to click an “I agree” button. Depending on where you were, it might have asked you for information about yourself, like your email, social media accounts, room number (in a hotel), account number (in a library), or other identifying information. Sometimes you even have to watch a short video or ad before wifi access is granted.

These kinds of screens are called captive portals, and they interfere with wireless security without providing many user benefits.

Read more at EFF

How Kubernetes Certificate Authorities Work

Today, let’s talk about Kubernetes private/public keys & certificate authorities!

This blog post is about how to take your own requirements about how certificate authorities + private keys should be organized and set up your Kubernetes cluster the way you need to.

The various Kubernetes components have a TON of different places where you can put in a certificate/certificate authority. When we were setting up a cluster I felt like there were like 10 billion different command line arguments for certificates and keys and certificate authorities and I didn’t understand how they all fit together.

Read more at Julia Evans

Open Source Leaders: Solomon Hykes and the Docker Revolution

Hykes likes to try new ideas and new things. “If they work I keep it. If it doesn’t work I try something else,” said Hykes. At Docker, they call themselves builders. “We like to build new things and if they’re useful we build more of them and if they’re not useful we try something else. It’s almost like a way of life.”

He believes that the open-source community traditionally has been a home for that kind of approach. It’s always been attractive for builders to work in an environment where there’s a direct feedback loop.

“It’s you, your code and either it works or it doesn’t. Either people adopt it or not. There’s less layers of indirection and ambiguity. I think that’s attractive to a lot of open-source contributors. We’re trying to follow that philosophy,” said Hykes.

Read more at The New Stack

Top 4 Reasons I Use dwm for my Linux Window Manager

I like minimalistic views. If I could run everything in a terminal I would. It’s free from shiny stuff that hogs my resources and distracts my feeble mind. I also grow tired of resizing and moving windows, never getting them to align perfectly.

On my quest for minimalism, I grew fond of Xfce and used it as my main desktop environment for years on my Linux computers. Then, one day I came across a video of Bryan Lunduke talking about the awesome window manager he used called Awesome. It neatly arranges all of your windows for you, and so, sounded like just what I wanted. I tried it out but didn’t get the hang of the configuration needed to tweak it into my liking. So, I moved on and discovered xmonad, but I had a similar result. It worked fine but I couldn’t get around the Haskell part to really turn it into my perfect desktop.

Read more at OpenSource.com

Linux Foundation Open Source Summit Talk: “Developing an Open Source Strategy — The First 90 Days”

“Open source culture” is something many of us who work with the open source community, either directly or indirectly, believe we have a handle on. There’s a general presumption that it should center around the concept of sharing ideas, and contribute to a broader ideal of building better software. But how should a business go through a transformative journey to an open source culture in 90 days?

At the forthcoming Open Source Summit in Los Angeles, Nithya A. Ruff, who directs the open source practice for CATV provider and content producer Comcast, will speak on the subject of building an open source culture within organizations in a 90-day time span. We spoke with Ruff about her upcoming talk.

When you join a company to build the OSS strategy, what are the factors that you consider first?

There really are three factors to look at. First, what business is the company in, and how can open source be an innovation driver in that business? Your open source strategy needs to align with the company business and software strategy, and not be separate.

Read more at The New Stack

How to Calculate Network Addresses with ipcalc

The math behind IP addresses is convoluted. Our nice IPv4 addresses start out as 32-bit binary numbers, which are then converted to base 10 numbers in four 8-bit fields. Decimal numbers are easier to manage than long binary strings; still, calculating address ranges, netmasks, and subnets is a bit difficult and error-prone, except for the brainiacs who can do binary conversions in their heads. For the rest of us, meet ipcalc and ipv6calc.

ipcalc is for IPv4 networks, and ipv6calc is for IPv6 networks. Today, we’ll play with IPv4, and next week IPv6.

You must understand Classless Inter-Domain Routing (CIDR) as this is fundamental to IP addressing; if you don’t, please look it up. (See Practical Networking for Linux Admins: Real IPv6 for a concise description.)

ipcalc

Run ipcalc with your IP address to see everything you need to know:

$ ipcalc 192.168.0.135
Address:   192.168.0.135        11000000.10101000.00000000. 10000111
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   192.168.0.0/24       11000000.10101000.00000000. 00000000
HostMin:   192.168.0.1          11000000.10101000.00000000. 00000001
HostMax:   192.168.0.254        11000000.10101000.00000000. 11111110
Broadcast: 192.168.0.255        11000000.10101000.00000000. 11111111
Hosts/Net: 254                   Class C, Private Internet

What I especially like about ipcalc is seeing the binary form of IP addresses, which clearly shows what netmasks do. These don’t make much sense in dotted decimal notation, but in binary they are as clear as can be. A mask covers things, and in this example it’s plain that the 24-bit netmask covers the first three quads. The first three quads make up the network ID, and the final quad is the host address.

ipcalc tells us the network range (192.168.0.0/24), the first and last available host addresses (192.168.0.1 and 192.168.0.254), and that it’s a Class C private network. Each 8-bit field contains values ranging from 0-255. The very first value in the host field, 0, is always reserved as the network address, and the last value, 255, is always reserved for the broadcast address, so you cannot use these as host addresses. ipcalc reports only available addresses, so in this example, that is 254 instead of 256.

Classful Networking

IPv4 networks have five classes: A, B, and C, which we use all the time, D, the multicast class, and E, which is experimental and reserved for future use. With the advent of IPv6, it’s likely class E will never be used. A picture is worth a thousand words, and this table from Classful network on Wikipedia shows the relationship from decimal to binary.

In the following table:

  • n indicates a bit used for the network ID.
  • H indicates a bit used for the host ID.
  • X indicates a bit without a specified purpose.
Class A
  0.  0.  0.  0 = 00000000.00000000.00000000.00000000
127.255.255.255 = 01111111.11111111.11111111.11111111
                  0nnnnnnn.HHHHHHHH.HHHHHHHH.HHHHHHHH

Class B
128.  0.  0.  0 = 10000000.00000000.00000000.00000000
191.255.255.255 = 10111111.11111111.11111111.11111111
                  10nnnnnn.nnnnnnnn.HHHHHHHH.HHHHHHHH

Class C
192.  0.  0.  0 = 11000000.00000000.00000000.00000000
223.255.255.255 = 11011111.11111111.11111111.11111111
                  110nnnnn.nnnnnnnn.nnnnnnnn.HHHHHHHH

Class D
224.  0.  0.  0 = 11100000.00000000.00000000.00000000
239.255.255.255 = 11101111.11111111.11111111.11111111
                  1110XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX

Class E
240.  0.  0.  0 = 11110000.00000000.00000000.00000000
255.255.255.255 = 11111111.11111111.11111111.11111111
                  1111XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX

In the first three classes, note the leading bits, which are the most significant bits. Class A has a leading bit of 0, which means the following 7 bits comprise the network ID, 0-127. Class B has 10, which converts to 128-191, and Class C is 110, 192-223.

You can calculate the total size of each class from the number of leading bits:

$ ipcalc 0.0.0.0/1 
[...]
Hosts/Net: 2147483646  Class A, In Part Private Internet

$ ipcalc 128.0.0.0/2
[...]
Hosts/Net: 1073741822  Class B, In Part APIPA

$ ipcalc 192.0.0.0/3
[...]
Hosts/Net: 536870910   Class C, In Part Private Internet

APIPA is Automatic Private IP Addressing, the range from 169.254.0.1 through 169.254.255.254. This is used primarily in Windows networks; DHCP clients automatically assign themselves one of these addresses when there is no DHCP server.

Private Networks

Most of us are familiar with the private IPv4 network ranges, because we can use these freely on our LANs without requesting globally unique address allocations from a service provider.

Class A  10.0.0.0/8
Class B  172.16.0.0/12
Class C  192.168.0.0/16

Plug any of these into ipcalc and see what it tells you.

Subnetting

Thanks to CIDR, we can finely slice and dice A, B, or C networks into multiple subnets, and ipcalc makes subnetting easy. Suppose you want to make two Class B subnets; just tell ipcalc the network segment you want to divide and how many hosts in each segment. In this example we want 15 hosts in each subnet:

$ ipcalc 172.16.1.0/24 -s 15 15
Address:   172.16.1.0           10101100.00010000.00000001. 00000000
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   172.16.1.0/24        10101100.00010000.00000001. 00000000
HostMin:   172.16.1.1           10101100.00010000.00000001. 00000001
HostMax:   172.16.1.254         10101100.00010000.00000001. 11111110
Broadcast: 172.16.1.255         10101100.00010000.00000001. 11111111
Hosts/Net: 254                   Class B, Private Internet

1. Requested size: 15 hosts
Netmask:   255.255.255.224 = 27 11111111.11111111.11111111.111 00000
Network:   172.16.1.0/27        10101100.00010000.00000001.000 00000
HostMin:   172.16.1.1           10101100.00010000.00000001.000 00001
HostMax:   172.16.1.30          10101100.00010000.00000001.000 11110
Broadcast: 172.16.1.31          10101100.00010000.00000001.000 11111
Hosts/Net: 30                    Class B, Private Internet

2. Requested size: 15 hosts
Netmask:   255.255.255.224 = 27 11111111.11111111.11111111.111 00000
Network:   172.16.1.32/27       10101100.00010000.00000001.001 00000
HostMin:   172.16.1.33          10101100.00010000.00000001.001 00001
HostMax:   172.16.1.62          10101100.00010000.00000001.001 11110
Broadcast: 172.16.1.63          10101100.00010000.00000001.001 11111
Hosts/Net: 30                    Class B, Private Internet

Needed size:  64 addresses.
Used network: 172.16.1.0/26
Unused:
172.16.1.64/26
172.16.1.128/25

I think that is pretty darned fabulous. Why does the example use 172.16.1.0/24? Trial and error: I ran ipcalc with different CIDR ranges until I found one close to the size I needed. 172.16.1.0/24 = 254 hosts per subnet, leaving room to grow.

16,777,214 Loopback Addresses

Did you know that the loopback address range is an entire Class A 8-bit range?

$ ipcalc 127.0.0.0/8
Address:   127.0.0.0            01111111. 00000000.00000000.00000000
Netmask:   255.0.0.0 = 8        11111111. 00000000.00000000.00000000
Wildcard:  0.255.255.255        00000000. 11111111.11111111.11111111
=>
Network:   127.0.0.0/8          01111111. 00000000.00000000.00000000
HostMin:   127.0.0.1            01111111. 00000000.00000000.00000001
HostMax:   127.255.255.254      01111111. 11111111.11111111.11111110
Broadcast: 127.255.255.255      01111111. 11111111.11111111.11111111
Hosts/Net: 16777214              Class A, Loopback

Try it for yourself — you can ping any address in this range. ping localhost returns 127.0.0.1 because most Linux distributions configure this in /etc/hosts.

Sorry, but that’s all the fun we can have today. Come back next week to learn how to tame those massive unwieldy IPv6 addresses with ipv6calc.

Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.

3 Open Source Projects That Make Kubernetes Easier

From cluster state management to snapshots and DR, companion tools from Heptio, Kubed, and Kubicorn aim to fill the gaps in Kubernetes.

Clearly, Kubernetes is an elegant solution to an important problem. Kubernetes allows us to run containerized applications at scale without drowning in the details of balancing loads, networking containers, ensuring high availability for apps, or managing updates or rollbacks. So much complexity is hidden safely away. 

But using Kubernetes is not without its challenges. Getting up and running with Kubernetes takes some work, and many of the management and maintenance tasks around Kubernetes are downright thorny. 

Read more at InfoWorld

How to Build Clusters for Scientific Applications-as-a-Service

How can we make a workload easier on cloud? In a previous article we presented the lay of the land for HPC workload management in an OpenStack environment. A substantial part of the work done to date focuses on automating the creation of a software-defined workload management environment – SLURM-as-a-Service.

SLURM is only one narrow (but widely used) use case in a broad ecosystem of multi-node scientific application clusters: let’s not over-specialize. It raises the question of what is needed to make a generally useful, flexible system for creating Cluster-as-a-Service?

What do users really want?

A user of the system will not care how elegantly the infrastructure is orchestrated:

  • Users will want support for the science tools they need, and when new tools are needed, the users will want support for those too.
  • Users will want to get started with minimal effort. The learning curve they must climb to deploy tools needs to be shallow.
  • Users will want easy access to the datasets upon which their research is based.

Read more at OpenStack SuperUser

The Cloud Native Architect

One of the biggest learning curves I ever endured in that time was working in an operations team building what I will call a virtualisation platform. They called it infrastructure as code, I called it automating previously manual processes using development techniques. It opened my mind again to a completely new way of looking at development teams outside of the DevOps culture. Development techniques were relatively new in that team but the real value was driven through collaborative knowledge share. System administrators were developing code and developers were gaining knowledge of automating and building up the infrastructure & networking of a cloud platform. At this point, this was the first time I had seen this degree of two-way communication outside of teams already building on a PaaS. This truly opened my eyes to the challenges these operations team face when the code is thrown over the fence and they are expected to agree to run it in production with confidence.

Historically the responsibilities of a production system were formed from an aggregated view of collective specialisms. For example: Infrastructure architects, network architects, security architects, QA, developers; technical and solution architects. What I am getting at here is that each role had a more narrow minded focus and set of key responsibilities.

Read more at Medium