Home Blog Page 691

Hyperledger Chain Gang Man Explains Penguins’ Blockchain Play

Jim Zemlin raises an eyebrow when I say Hyperledger is rather outside Linux Foundation’s usual domain, being a bit, er, consumery.

“It’s totally enterprise,” the Foundation’s executive director tells me. “It’s infrastructure.” Just like Linux, he reckons. Hyperledger is the layer above the operating system, above Linux.

Linux is the Linux Foundation’s oldest and hardest of hard-core projects – a technology fundamental that drives economies.

The Foundation went beyond Linux ages ago and in 2015 it set a record in starting new projects – 13, nearly half the Foundation’s total.

2016 has seen seven so far – network switch, network analytics and small footprint real time operating systems.

Read more at The Register

fswatch – Monitors Files and Directory Changes or Modifications in Linux

fswatch is a cross-platform, file change monitor that gets notification alerts when the contents of the specified files or directories are altered or modified.

It executes four types of monitors on different operating systems such as:

  1. A monitor build on the File System Events API of Apple OS X.
  2. A monitor based on kqueue, a notification interface present in FreeBSD 4.1 also supported on many *BSD systems, OS X inclusive.
  3. A monitor based on File Events Notification API of the Solaris kernel plus its spin-offs. …

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

The Most Important Coding Languages for IoT Developers

We have seen a changing of the guard in the past few years as software takes center stage and once-beloved hardware simply becomes a canvas for developers. The ability to code is an important skill for the production of any modern technology, especially a product that falls within the internet of things. If IoT developers are to create the next big thing in tech, they will need to know the most important and popular IoT coding languages. Here is a list of top coding languages providing the backbone of IoT software:

C

C, a language first developed to program telephone switches, is available on nearly every advanced embedded system platform that exists. For some platforms where it’s not directly available, it’s still the basis for the dedicated language used in the SDK.​

Read more at RCR Wireless News.

 

9 Useful Tips For Linux Server Security

Any serious systems can’t ignore server security, especially in public Cloud. No doubt there’re tons of tips and tutorials available on the Internet. Let’s focus on fundamental and general best practices first.
A List Of Security Improvements I Enforce After OS Provisioning.

linux_security.jpg


Original Article: http://dennyzhang.com/linux_security

Here we use Ubuntu 16.04 for instance.

1. Keep Kernel Up-To-Date.

Certainly no blind update for prod envs. But for newly installed servers, it’s usually harmless and can guarantee a higher level of security.

One common suggestion is disabling unused services. But I choose to trust my distros provider. Generally speaking, I believe they might make right choices to have what installed and enabled by default.

apt-get -y update

2. Reset Root password.

We need that to access web console of VMs. This happens when ssh doesn’t work. e.g. problematic iptables rules block you, OS runs into kernel panic, or machine reboot mysteriously stucks.

root_pwd="DevOpsDennyChangeMe1"
echo "root:$root_pwd" | chpasswd

3. Hardening SSHD.

Only allow ssh by keyfile, thus hackers can’t easily break-in by guessing your password. Use another ssh listening port other than 22, which can avoid annoying ssh login attempts.

# Disable ssh by password
sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/g' 
      /etc/ssh/sshd_config
sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/g' 
     /etc/ssh/sshd_config
grep PasswordAuthentication /etc/ssh/sshd_config

# Use another ssh port
sshd_port="2702"
sed -i "s/^Port 22/Port $sshd_port/g" /etc/ssh/sshd_config
grep "^Port " /etc/ssh/sshd_config

# Restart sshd to take effect
service ssh restart

4. Restrict Malicious Access By Firewall.

This might be the most important security improvement you shall do.

# Have a clean start with iptables
iptables -F; iptables -X
echo 'y' | ufw reset
echo 'y' | ufw enable
ufw default deny incoming
ufw default deny forward

# Allow traffic of safe ports
ufw allow 22,80,443/tcp

# Allow traffic from certain port
ufw allow 2702/tcp

# Allow traffic from trusted ip
ufw allow from 52.74.151.55

5. Add Timestamp To Command History.

It allows us to review what commands has been issued, and when.

echo export HISTTIMEFORMAT="%h %d %H:%M:%S " >> /root/.bashrc

6. Generate SSH Key Pair.

Never never share the same ssh key pair across servers!

exec ssh-agent bash

# General new key pair
ssh-keygen

# Load key pair
ssh-add

7. Pay Close Attention to var/log.

Use logwatch to automate the check and analysis. It’s a userful parsing perl script that analyzes and generates daily reports on your system’s log activity. Major log files:

  • /var/log/kern.log
  • /var/log/syslog
  • /var/log/ufw.log
  • /var/log/auth.log
  • /var/log/dpkg.log
  • /var/log/aptitude
  • /var/log/boot.log
  • /var/log/cron.log
  • /var/log/mailog
apt-get install -y logwatch

# Full check. Takes several minutes
logwatch --range ALL

# Only check log of Today
logwatch --range Today

# Check log for last week
logwatch --range "between -7 days and -1 days"

8. Run 3rd Security Check Tools.

Not everyone can or will be a security expert. Better try reliable and versatile tools. lynis is quite handy and straight-forward. Just a single bash file.

apt-get install -y lynis

# Run lynis to check security issues
lynis -c

9. Proper Backup Unrecoverable Data.

Always has plan B. As the last resort, make it’s feasible to do a quick system restore in new servers.

Special thanks to this reddit discussion.

More Reading: Detect Suspicious Linux Processes


Like our blog posts? Discuss with us on LinkedIn, Twitter Or NewsLetter.

In the Future, Intelligent Bots Might Have to Pay For Their Own Server Space to Stay Alive

…it appears we are drowning in an overabundance of a world where there’s an app for almost anything, leading to some rumblings of increasing “app fatigue” among consumers who are tired of juggling between or updating apps, or understandably cautious due to security concerns.

But here’s where a new generation of artificially intelligent bots might come in to help mediate between the apps needed to get a task done. We’re not talking about web crawling bots, pesky spambots nor chatbots gone wild.

As an alternative to the standalone application, Armenian startup Bazillion Beings is proposing the creation of what it calls “independent online life forms” — “micro AIs” which are mashups of apps, APIs and other microservices, forming a new, emergent entity that can get a specific task done much more quickly and efficiently. Automation is achieved by connecting disparate apps together to help you pay your bills on time, plan your next restaurant outing, and more — all without needing you to switch around between apps on your phone.

Read more at The New Stack

Automation Is Not DevOps

Nor is any technology or product.

I should remind a famous quote:

“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”

Bill Gates

It may sound counterproductive from an Automation specialist to reveal the limitations of his job, but I have seen a wide range of inefficiencies, and many failed attempt to fix them.

To be clear from the outset, I do think technology and automation are a mandatory milestone in a company’s DevOps journey, but they are no more than tools or enabler to achieve something bigger: help delivering the business value people expect when you mention that term: DevOps.

Read more at DevOps Collective

OCI Announces Two New Tools Projects

With ContainerCon Europe currently underway in Berlin, we want to share some of the great progress the Open Container Initiative (OCI) has made.

The OCI was launched with the express purpose of developing standards for the container format and runtime that will give everyone the ability to fully commit to container technologies today without worrying that their current choice of infrastructure, cloud provider or tooling will lock them in. 

Last month, the OCI formed two new tools projects: runtime tools and image tools. These projects are associated with the OCI runtime spec and image format spec and serve as repositories for testing tools:

  • Runtime Tools: Tools for testing container runtimes implementing the OCI runtime spec, including code that tests a runtime’s conformance to the OCI runtime spec
  • Image Tools: Tools for testing of container images implementing the OCI image spec, including code that validates a file’s conformance to the OCI image format spec

We’ve also made significant progress on the runtime spec and image format spec, which are essential to furthering the proliferation and adoption of containers as they give companies confidence in the ability to move their containers between clouds.

In order to encourage ongoing, consistent communication and consensus-building during the development process, the OCI release process requires at least three release candidates (rc) before declaring v1.0.  We are currently on the second release candidate for the runtime spec (v1.0.0 – rc2) and the first release candidate for the image spec (v1.0.0 – rc1).

As an open source project, any developer or end user can make contributions to the OCI, and we welcome feedback from the community on these release candidates and the new tools projects as we get closer to the official v1.0 release. 

Projects associated to the Open Container Initiative can be found at https://github.com/opencontainers and you can learn more about joining the OCI community  athttps://www.opencontainers.org/community.

This article originally appeared on the OCI website.

Transitioning from OpenStack Hobbyist to Professional

The hardest part of pivoting your career is proving that you are qualified in your new focus area. To land your first OpenStack job, you’ll want to prove you have a functional understanding of OpenStack basics, can navigate the resources to solve problems, and have recognized competency in your focus area.

“A functional understanding of OpenStack” means you know how to work in OpenStack––not just naming the projects in alphabetical order or giving an overview of its history. While you’ll want to read up on its origins and future roadmap, you’ll also want to jump in by using tools like DevStack or TryStack to explore.

Many people find find courses and training helpful for gaining that “functional understanding.” Some take training because they want to get up to speed quicker than they would on their own; some because they want to make sure they correctly learn the nuances of OpenStack; some because their learning styles are more accustomed to a classroom environment. Whatever the reason, there’s no shortage of OpenStack courses. You can visit the OpenStack Training Marketplace to scroll through courses and pick from online, in-person, self-paced, or designated hour courses. Course levels range from beginner to advanced. Stacker Tip: Trainings and workshops are included in full access passes at the OpenStack Summit. You can grab a remaining spot at OpenStack Summit Barcelona, or keep an eye out for early bird pricing to OpenStack Summit Boston in the upcoming months for the ultimate savings.     

The additional areas you’ll want to show competency in will depend on your focus area. If you’re a developer, be ready to demonstrate your Python skills and show your knowledge of orchestration tools like Ansible or Puppet. Participating in OpenStack code reviews is a great way to get involved in the community and display your abilities.

For administrators, the Certified OpenStack Administrator (COA) exam should be your first step. Developers shouldn’t write off admin certification though; in both cases, passing the COA proves you have mastery of the two standard client sets (Horizon and the command line client) and an understanding of the system you’re working on. Whether you’re self-taught or took a course, you’ll want to have your skills evaluated against a standardized set of criteria that’s recognizable to employers. Certification signals to employers where your skill level is, and shows that you’re ready to work on OpenStack professionally.  

The COA exam is the only certification offered by the OpenStack Foundation. The exam was created through the collaboration of a variety of ecosystem companies. What this means is that someone who has passed the COA can work on OpenStack with any organization regardless of the distribution they’ve chosen as opposed to vendor-provided certifications which test skills around their OpenStack service offering.

The COA is a functional, task-based test, rather than multiple choice where candidates are asked to perform tasks frequently seen in a professional administrator role. It mirrors a real-world work environment in which you are tasked with solving a problem, using documentation and other resources to find answers, and creating an effective solution.    

You can review the areas covered on the COA to determine if you’re ready. If you’re unsure about your preparation, there are training partners who specialize in preparing people for the COA. Look for the COA logo in the lower righthand corner of listings in the OpenStack Training Marketplace.

The OpenStack community is continuing to grow, evolve and help users create solutions powered by open source. There’s plenty of space for everyone at the OpenStack table, and no shortage of professional options. We encourage to visit openstack.org/join to find out more ways to get involved, and follow us on Twitter at @OpenStack.

Want to learn the basics of OpenStack? Take the new, free online course from The Linux Foundation and EdX. Register Now!

The OpenStack Summit is the most important gathering of IT leaders, telco operators, cloud administrators, app developers and OpenStack contributors building the future of cloud computing. Hear business cases and operational experience directly from users, learn about new products in the ecosystem and build your skills at OpenStack Summit, Oct. 25-28, 2016, in Barcelona, Spain. Register Now!

Making Sense of Cloud Native Applications, Platforms, Microservices, and More

As more and more of our infrastructure moves into the cloud, the proliferation of buzzwords, new terms, and new ways of doing things can be daunting. Fabio Chiodini, Principal System Engineer at EMC, spent some time helping us make sense of these concepts during his LinuxCon Europe talk, “Cloud Native Applications, Containers, Microservices, Platforms, CI-CD…Oh My!!”

Fabio started by talking about the companies that are transforming their industries. We naturally think about the “unicorn” companies from Silicon Valley:

  • Netflix in the $53 billion entertainment industry
  • Square in the $6 billion financial services industry
  • AirBnB in the $26 billion hotel industry
  • Tesla in the $34 billion automotive industry
  • Uber in the $50 billion transportation industry
  • Nest in the $3.2 billion industrial products industry

But, the transformation is not restricted to the new and emerging Silicon Valley companies, traditional enterprise customers are delivering software in similar ways:

  • Lockheed Martin using Spring Framework with Pivotal Cloud Foundry as a cloud native Platform
  • Kroger adopting DevOps practices with a Pivotal Cloud Foundry automated build pipeline
  • Mercedes-Benz working on connected cars and smart apps
  • Bosch creating an IoT suite

Fabio defines cloud native applications as “applications that do not require resilient infrastructure,” which is a more concise version of Duncan C. E. Winn’s definition from his Cloud Foundry book, “Cloud native is a term describing software designed to run and scale reliably and predictably on top of potentially unreliable cloud-based infrastructure. Cloud native applications are purposefully designed to be infrastructure unaware, meaning they are decoupled from infrastructure and free to move as required.” However, Fabio also admits that there are many different definitions depending on what aspect of cloud someone is focused on.

If you look at the application lifecycle, Fabio talks about how some of these concepts fit together starting with microservices in the design phase moving from monolithic tightly coupled applications to loosely coupled components where each on can be deployed in an automated fashion without waiting on other components. In the deploy phase, he talked about Continuous Integration (CI) / Continuous Deployment (CD) moving from infrequent releases to releasing early and often resulting in a higher quality of code as bugs are fixed and deployed to production more quickly rather than sitting unfixed between releases. In the manage phase, a DevOps mindset is helping people move from disconnected tools and opaque processes to one of shared responsibility with common incentives, tools, process and culture. 

He discussed how this results in “new requirements for IT to deploy and deliver applications reliably at scale,” putting the focus on flexibility over reliability. He broke this down into four cloud native platform requirements:

  • Programmability: “Infrastructure As Code”
  • Elasticity: make it easy to scale
  • Economics: affordability with standard servers and software
  • Strong Instrumentation And Telemetry: metrics and monitoring of the infrastructure layer

Fabio also included a few demos to illustrate these concepts, which can be found in his ProjectSpawnSwarmtc and ReceiverCF GitHub repositories.

There are clear and solid business needs for cloud native applications with many options and technologies available. A structured approach with a simplified, flexible infrastructure offers many advantages for companies moving to cloud native applications.

The Evolution of Open Source Networking at AT&T

For many years AT&T has been on the forefront of virtualizing a Tier 1 carrier network. They’ve done so in a very open fashion and are actively participating in, and driving, many open sources initiatives.  Their open initiatives include Domain 2.0, ECOMP, and CORD, all of which are driving innovation in the global service provider market.  Chris Rice, Sr. VP of Domain 2.0 Architecture and Design of AT&T, provided an overview of how AT&T got where they are today during his keynote address at the ODL Summit.

Providing a bit of history of this journey, Rice noted that today’s implementations and visions started years ago. One of the first steps was the creation of what he called a router farm, which was initiated because of the end of life of a router and there wasn’t a new router that could just take its place. The goal was to remove the static relationship between the edge router and the customer. Once this was done, AT&T could provide better resiliency to their customers, detect failures, do planned maintenance, and schedule backups. They could also move configurations from one router to another vendor’s router.   The result was faster and cheaper; however, “it just wasn’t as reusable as they wanted.” They learned the importance of separating services from the network and from the devices.

About three and a half  years ago, the greater community and ecosystem started to address many of the company’s key concerns. For example, Rice noted that Intel was continuing to improve the packet processing performance of their general purpose CPUs, resulting in a 100 times improvement over a 10-year period. What they concluded was that “next-generation carrier networks must be: cloud-based, model-driven, and software defined.” He acknowledged that today this might not sound exciting but three and a half years ago, it was insightful.   

ECOMP and VNF

During this time ECOMP (Enhanced Control, Orchestration, Management and Policy) was born.  Rice noted that ECOMP is “not a science project.”  It was fully vetted and has been used in production networks for the past 2 years. Today, ECOMP comprises more than 8.5 million lines of code and is growing every day.  Rice also noted that currently 5.7 percent of AT&T’s network is virtualized and the goal is for 30 percent to be virtualized by the end of 2016.  

The Layer 2/3 SDN controller within ECOMP is based on ODL and includes a Layer 4-7 VNF management and application controller. Rice noted that a key takeaway was that ODL can be used at all layers of the OSI Stack. The layer 4-7 application controller is used to initialize and configure virtual network functions (VNFs), automate the lifecycle of VNFs, and to correct and monitor faults and failures of application components. He pointed out that all of this is being achieved in a vendor and VNF agnostic mechanism.

Legos Not Snowflakes

Perhaps the biggest takeaway from Rice’s keynote was his comment that today’s VNFs are “snowflakes and we want Lego blocks not snowflakes.” Lego blocks come in different shapes and colors yet they all interoperate. And, if each VNF is unique, it requires a costly and time consuming “one off” integration effort.  With the Lego model, they can build a framework or a foundation once and add or replace interoperable VNFs as required.  

There are functions that all VNFs must support regardless of their specific functionality. Rice noted that AT&T must be able to configure, test, scale, start, stop, restart, and rebuild every VNF no matter what its specific function. The industry as a whole, he continued, must work to normalize VNFs to support the common operational framework, the Lego model.  To illustrate their success in this model, Rice discussed their work with the optical transport part of their network. Using their methodology, AT&T has achieved end-to-end multi-vendor interoperability and can configuring and reconfiguring multiple vendors ROADMs.

Rice finished his talk by highlighting “why ODL.” First, ODL controllers are platforms for innovation. The   innovation occurs in both the way networks are built and in the way services are designed. Second, programmable controllers, such as within ODL, must support a rich set of both Northbound/Southbound interfaces as well as East/West capabilities. Rice noted here that the support for what he referred to as “brownfield” protocols is a mandatory requirement. Third, Rice called on the ODL community to focus on reliability and on scale and specifically called out the need for geographical redundancy.