Staying competitive in the managed services business today means keeping on top of the latest DevOps trends and developments. Here’s a look at how the DevOps world is evolving now.
It’s 2017, and Docker containers and continuous delivery are old news. More innovative developments are now shaping the world of DevOps.
They include:
Serverless computing. Serverless computing is not new. Serverless platforms have been around since the mid-2000s. But modern serverless services, such AWS Lambda and OpenWhisk, have made serverless computing more accessible and cost-efficient. Organizations seeking leaner, meaner solutions for deploying applications will increasingly look toward serverless computing.
Developers with Canonical pushed out a handful of patches for the Linux-based operating system Ubuntu this week, including one that resolves a bug that could have let an attacker cause a denial of service or execute arbitrary code with a TCP payload.
Chris Coulson, a software and electronics engineer with the company, discovered the vulnerability, an out-of-bounds write (CVE-2017-9445) in Ubuntu’s systemd-resolved system service. The service-an init system used in Linux distributions–is a network name resolution manager and helps provide network name resolution to local apps.
Coulson warned earlier this week the bug could affect any Linux distribution running an unpatched version of systemd.
Submit your proposal soon to speak at Open Source Summit and Embedded Linux Conference (ELC) taking place in Prague, Czech Republic, October 23-25, 2017. The deadline for proposals is Saturday, July 8, 2017. Don’t miss out on this opportunity to share your expertise and experience at these events.
At the Open Source Summit, you have the chance to learn, collaborate, and share information along with 2,000 peers and community members. We encourage the open collaboration and discussions that are necessary to keep Linux successful. And, if you’re interested in making a difference in Linux, open cloud, and open source, submit a speaking proposal soon!
For 12 years, ELC has had the largest collection of sessions dedicated exclusively to embedded Linux and embedded Linux developers. At ELC, you can collaborate with peers on all aspects of embedded Linux from hardware to user space development. Submit your proposal and join the conversation.
We invite you to share your creative ideas, enlightening case studies, best practices, or technical knowledge at these exciting events.
Linux Foundation events are an excellent way to get to know the community and share your ideas and the work that you are doing. You don’t need to be a core kernel maintainer or a chief architect to submit a proposal. In fact, we strongly encourage first-time speakers to submit talks for all of our events.
Our events are working conferences intended for professional networking and collaboration, and we work closely with our attendees, sponsors, and speakers to help keep Linux Foundation events professional, welcoming, and friendly.
Visit the OS Summit CFP page or the ELC Europe CFP page for suggested topics, submission guidelines, and other useful information. Submissions must be received by 11:59pm PST on Saturday, July 8, 2017.
We’re cruising now. We know important basics about TCP/IP and IPv6. Today we’re learning about private and link-local addressing. Yes, I know, I promised routing. That comes next.
Private Address Spaces
IPv4 and IPv6 both have private address spaces. These are not meant to leave your private network, and you may use them without requesting assignments from an official authority, like your Internet service provider. Or, if you’re a bigwig, a direct allocation from a regional Internet registry.
IPv4 Private Addresses
You’re probably familiar with IPv4 private addressing, as we’ve all been using it since forever. There are four different private address spaces:
10.0.0.0/8 (10.0.0.0 to 10.255.255.255), 16,777,216 addresses
172.16.0.0/12 (172.16.0.0 to 172.31.255.255), 1,048,576 addresses
192.168.0.0/16 (192.168.0.0 to 192.168.255.255), 65,536 addresses
169.254.0.0/16 (169.254.0.0 to 169.254.255.255), 65,536 addresses
Let’s talk about the last one first, 169.254.0.0/16, because I find it annoying. I never warmed up to it because it just gets in my way. That is the link-local auto-configuration block, also called Avahi Zeroconf. Microsoft Windows and some Linux distributions use these, so even when you don’t assign an IP address to a network interface, or it does not receive one via DHCP, it will get a 169.254.0.0/16 address. What’s the point? Supposedly easy ad hoc networking, and enabling communication with a host when other means of address assignment fail. Link-local addresses are accessible only within their own broadcast domains and are not routable. I’ve been disabling it since forever without missing it. If you find it useful, perhaps you could share a comment on how you use it.
The other three address spaces are routable, even outside your LAN. That is why most firewall tutorials include rules to stop these from leaving your network. Most ISPs block them as well.
The four hexadecimal octets in IPv4 addresses are conversions from binary. This is a fun topic for another day; you might investigate it because IPv4 addressing makes more sense in binary. For everyday use, this is what you need to know:
Each octet is 8 bits, and the total is 32 bits.
10.0.0.0/8 means the subnet mask is 8 bits, 255.0.0.0. You cannot change the first octet, 10, which is the network ID. The remaining three octets are the host ID, 24 bits, and you can change them however you like. Each octet has possible values ranging from 0-255. 10.0.0.0 and 10.255.255.255 are reserved and you cannot use them for host addresses, so your usable addresses are 10.0.0.1 to 10.255.255.254.
172.16.0.0/12 has a 12-bit subnet mask, 255.240.0.0, which does not divide up neatly into hexadecimal octets. 172.16.0.0 and 172.31.255.255 are reserved and you cannot use them, so your usable addresses are 172.16.0.1 to 172.31.255.254.
192.168.0.0/16 has a 16-bit subnet mask, 255.255.0.0. Again, the first and last addresses are reserved, so your usable addresses are 192.168.0.1 to 192.168.255.254.
So, you ask, just what are the first and last addresses reserved for? The first address identifies your subnets, for example 192.168.1.0. The last address is the broadcast address. Suppose your subnet is 192.168.1.0/24, then 192.168.1.255 is the broadcast address. These broadcasts go to every host on the network segment, hence the term “broadcast domain”. This is how DHCP and routing tables are advertised.
IPv6 Private Addresses
IPv6 private link-local addresses, for whatever reason, are not pebbles in my shoes the way IPv4 link-local addresses are. Maybe because they’re so alien they bounce off my brain. And I have no choice, as the IPv6 protocol requires these. You can view yours with either the ip or ifconfig command:
These fall into the fe80::/10 range. You can ping your computer:
$ ping6 -I wlan0 fe80::b07:5c7e:2e69:9d41
PING fe80::b07:5c7e:2e69:9d41(fe80::b07:5c7e:2e69:9d41)
from fe80::b07:5c7e:2e69:9d41 wlan0: 56 data bytes
64 bytes from fe80::b07:5c7e:2e69:9d41:
icmp_seq=1 ttl=64 time=0.032 ms
With ping6, you must always specify your interface name, even if it is the only one. You can discover your LAN neighbors:
$ ping6 -c4 -I wlan0 ff02::1
PING ff02::1(ff02::1) from fe80::b07:5c7e:2e69:9d41
wlan0: 56 data bytes
64 bytes from fe80::b07:5c7e:2e69:9d41:
icmp_seq=1 ttl=64 time=0.078 ms
64 bytes from fe80::4066:50ff:fee7:3ac4:
icmp_seq=1 ttl=64 time=20.7 ms (DUP!)
64 bytes from fe80::9eef:d5ff:fefe:17c:
icmp_seq=1 ttl=64 time=27.7 ms (DUP!)
Cool, I have two neighbors. ff02::1 is a special link-local multicast address for discovering all link-local hosts. man ping tells us that DUP! means “ping will report duplicate and damaged packets. Duplicate packets should never occur, and seem to be caused by inappropriate link-level retransmissions.” In this context, it’s nothing to worry about, so I ping my neighbors:
$ ping6 -c4 -I wlan0 fe80::4066:50ff:fee7:3ac4
64 bytes from fe80::4066:50ff:fee7:3ac4:
icmp_seq=1 ttl=64 time=4.72 ms
How is it that we can ping our LAN neighbors on their link-local addresses, when we couldn’t ping the 2001:0DB8::/32 addresses we created in last week’s installment? Because the routing is automatic. You won’t see IPv6 routes with the good ol’ route command, but must use the ip command:
$ ip -6 route show
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
Pretty slick. Come back next week, and we will really do some routing.
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.
At the recent Automotive Linux Summit, held May 31 to June 2 in Tokyo, The Linux Foundation’s Automotive Grade Linux (AGL) project had one of its biggest announcements in its short history: The first automobile with AGLs open source Linux based Unified Code Base (UCB) infotainment stack will hit the streets in a few months.
In his ALS keynote presentation, AGL director Dan Cauchy showed obvious pride as he announced that the 2018 Toyota Camrywill offer an in-vehicle infotainment (IVI) system based on AGL’s UCB when it debuts to U.S. customers in late summer. Following the debut, AGL will also roll out to most Toyota and Lexus vehicles in North America.
AGL’s first design win is particularly significant in that Toyota owns 14 percent of the U.S. automotive market. The Japanese automaker recently eclipsed GM as the world’s leading carmaker with an 11 percent global share.
The announcement came around the same time that Google tipped plans for an expansion of its Android Auto project for mobile communications with IVI systems to a comprehensive Android Automotive IVI project. TheAndroid Automotive stack will first appear on Audi and Volvo cars, with the first Volvo model expected in two years.
If all goes to plan, Toyota’s 2018 Camry rollout will occur just over three years after AGL released its initial automotive stack based on Tizen IVI. This was followed a year later by the first AGL Requirements Specification, and then the UCB 1.0, an overhauled version based on Yocto Project code instead of Tizen.
Rapid development
That may seem like a long road compared to many open source projects, but it’s remarkably rapid for the comparatively sluggish automotive market. During that same period, AGL has also racked up an impressive roster of members, including automotive manufacturers like Ford, Honda, Jaguar Land Rover (JLR), Mazda, Mitsubishi, Nissan, and Subaru, Toyota. Other members include most of the major Tier 1 system integrators, as well as a growing list of software and services firms.
In his keynote, Cauchy seemed genuinely surprised at how quickly AGL has grown. “Back in 2015 at our first meeting, we had four core members — Honda, JLR, Nissan, and Toyota — and today we have 10 OEM automotive manufacturers,” said Cauchy. “In 2015, we had 55 members, and we now have 98. We’re seeing a whole range of companies including middleware and services developers, voice recognition and navigation companies, and telecom companies that want to be part of the connected car. We have over 750 developers on the primary AGL mailing list.”
The pace is faster compared to Cauchy’s previous experience acting as a GENIVI Alliance board member and chairman of GENIVI Compliance back when he was developing an IVI platform at MontaVista. GENIVI eventually signed up a similar lineup of companies for its Linux-based, mostly open source IVI standard, but the momentum started flagging when it became clear that the standard was not solid enough to permit significant reuse of code from vendor to vendor.
AGL’s UCB is the specification
Many of the same companies have since joined AGL, which integrates some GENIVI code. The key difference is that instead of defining a specification, AGL’s UCB is the specification. Everyone agrees to use the same Linux distribution and middleware, while leaving the top layers customizable so each manufacturer can differentiate.
“AGL exists because the automakers realize they’re in the software business,” Cauchy told the ALS attendees. “AGL is a code first organization — we believe that specifications lead to fragmentation. Today, you have Microsoft and QNX and multiple flavors of Linux, and there’s no software reuse.”
As AGL Community Manager Walt Miner explained in a February presentation at the Embedded Linux Conference, GENIVI never pushed the specification far enough to be useful. “With specifications, multiple vendors can claim compliance, but you end up with different platforms with slightly different code,” said Cauchy. “We’re about building a single platform for the whole industry so you can port your software once, and it’s going to work for everyone.”
The ability to reuse code leads to faster time to market, which will soon enable new IVI systems to roll out every year rather than every three years, said Cauchy. As a result, consumers will be less tempted to navigate and play music from a cell phone placed on the dashboard with all the safety hazards that implies.
New model
“We want to break that old supply chain model with a new model where the platform survives and evolves,” said Cauchy. “This will bring the industry on par to what consumers are expecting, which is more like cell phones.”
Cauchy went on to discuss the evolution of UCB last year from Agile Albacore to Brilliant Blowfish and then Charming Chinook. “The industry can now rely on us to have a release every six months, so companies can make product and deployment plans.”
Cauchy also announced release candidate 1 of Daring Dab, which will be available in a final release on July 22. As Miner explained at ELC, Daring Dab will tap Yocto Project 2.2 code, as well as secure signaling and notifications, smart device link, and application framework improvements such as service binders for navigation, speech, browser, and CAN. An Electric Eel release will follow in six months with features like back ends for AGL reference apps working in both Qt 5 and HTML5.
Electric Eel may also include the first implementation of a headless telematics profile. “We’re redefining our architecture in layers so we can properly support a headless profile that runs on a lower performance chip and doesn’t need a display or infotainment,” said Cauchy. “We want to build our requirements out for ISO 26262 functional safety compliance to see if we can use the Linux kernel.”
Beyond that, AGL will move into instrument cluster and heads up displays, followed by ADAS “and eventually autonomous driving,” said Cauchy. “We want to be in every processor and every function in the car. This is really taking off.”
Learn more from Automotive Linux Summit, which connects the community driving the future of embedded devices in the automotive arena. Watch the videos from the event.
Open source software (OSS) projects start with the intention of creating technology that can be used for the greater good of the technical, or global, community. As a project grows and matures, it can reach a point where the goals of or perspectives on the project diverge. At times like this, project participants start thinking about a fork.
Forking an OSS project often begins as an altruistic endeavor, where members of a community seek out a different path to improve upon the project. But the irony of it is that forking is kind of like the OSS equivalent of the third rail in the subway: You really don’t want to touch it if you can help it.
As Marty Cagan, founding partner of Silicon Valley Product Group and a 30-year veteran of product management, puts it, “The job of a product manager is to discover a product that is valuable, usable, and feasible.” Similarly, co-author Martin Eriksson, in his oft-quoted definition of product management, calls it the intersection between business, user experience, and technology (see Figure 1; only a product manager would define themselves in a Venn diagram!). A good product manager must be experienced in at least one, passionate[1] about all three, and conversant with practitioners of all three. …
Perhaps most importantly, the product manager is the voice of the customer inside the business, and thus must be passionate about customers and the specific problems they’re trying to solve. This doesn’t mean the product manager should become a full-time researcher or a full-time designer, but they do need to make time for this important work.
Kubernetes presumes deep private cloud knowledge. If your organization isn’t there yet, evaluate the supported Kubernetes distributions from third-party as-a-service vendors. Organizations can offload some of the heavy lifting to deploy containers with Kubernetes as a service from a hosting company.
Docker containers have a steep learning curve because of the intrinsic paradigm shift from hardware virtualization to OS-level abstraction. Developers and IT pros know how to interact with line-of-business applications through VMs, but Docker packages an application with all its dependencies into portable containers that share an OS and run on different host servers with different hardware platforms.
Cloud Foundry falls under the “platform-as-a-service” (PaaS) umbrella, which essentially makes it the PaaS counterpart to OpenStack’s “infrastructure-as-a-service.” The promise of Cloud Foundry is that it abstracts all of the grunt work of running the infrastructure and more high-level services like databases away and gives developers a single platform to write their applications for.
The premise here is that what sits underneath Cloud Foundry shouldn’t have to matter to the developer. That can be an on-premises OpenStack cloud or a public cloud like AWS, Google Cloud Platform, IBM Bluemix or Azure. This also means that companies get the ability to move their applications from one cloud to another (or use multiple clouds simultaneously) without having to adapt their code to every cloud’s peculiarities. As Cloud Foundry Foundation CTO Chip Childers told me, the project wants to make developers happy (and productive).
The Linux Foundation is announcing a new open-source project designed to bring automated protection to software-defined networks. The Open Security Controller (OSC) Project is a new software-defined security orchestration solution with a focus on multi-cloud environments.
“Software-defined networks are becoming a standard for businesses, and open source networking projects are a key element in helping the transition, and pushing for a more automated network” said Arpit Joshipura, general manager of Networking and Orchestration at The Linux Foundation. “Equally important to automation in the open source community is ensuring security. The Open Security Controller Project touches both of these areas. We are excited to have this project join The Linux Foundation, and look forward to the collaboration this project will engender regarding network security now and in the future.”
