Open-source News

Imagination's PowerVR Open-Source Vulkan Driver Lands Hard Coding Infrastructure

Phoronix - Mon, 06/20/2022 - 18:11
Due to the early state of Imagination's PowerVR Rogue open-source Vulkan driver within Mesa a "hard coding" infrastructure has been added for helping to load hard-coded graphics/compute shaders into this driver until its compiler is far enough along to be useful and mark this infrastructure as unnecessary/redundant...

X Window System Turns 38 Years Old

Phoronix - Mon, 06/20/2022 - 17:42
This weekend marked 38 years since the inaugural release of the X Window System at MIT...

Meson 0.63.0rc1 Brings Support For Mold, Improvements For Windows Cross-Compiling

Phoronix - Mon, 06/20/2022 - 17:14
Sunday marked the release of the Meson 0.63 release candidate for this increasingly popular open-source, cross-platform build system...

20 Useful Security Features and Tools for Linux Admins

Tecmint - Mon, 06/20/2022 - 15:14
The post 20 Useful Security Features and Tools for Linux Admins first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

In this article, we shall a list of useful Linux security features that every system administrator should know. We also share some useful tools to help a system admin ensure security on their Linux

The post 20 Useful Security Features and Tools for Linux Admins first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

How I use the attr command with my Linux filesystem

opensource.com - Mon, 06/20/2022 - 15:00
How I use the attr command with my Linux filesystem Seth Kenlon Mon, 06/20/2022 - 03:00 Register or Login to like Register or Login to like

The term filesystem is a fancy word to describe how your computer keeps track of all the files you create. Whether it's an office document, a configuration file, or thousands of digital photos, your computer has to store a lot of data in a way that's useful for both you and it. Filesystems like Ext4, XFS, JFS, BtrFS, and so on are the "languages" your computer uses to keep track of data.

Your desktop or terminal can do a lot to help you find your data quickly. Your file manager might have, for instance, a filter function so you can quickly see just the image files in your home directory, or it might have a search function that can locate a file by its filename, and so on. These qualities are known as file attributes because they are exactly that: Attributes of the data object, defined by code in file headers and within the filesystem itself. Most filesystems record standard file attributes such as filename, file size, file type, time stamps for when it was created, and time stamps for when it was last visited.

I use the open source XFS filesystem on my computers not for its reliability and high performance but for the subtle convenience of extended attributes.

Common file attributes

When you save a file, data about it are saved along with it. Common attributes tell your operating system whether to update the access time, when to synchronize the data in the file back to disk, and other logistical details. Which attributes get saved depends on the capabilities and features of the underlying filesystem.

In addition to standard file attributes (insofar as there are standard attributes), the XFS, Ext4, and BtrFS filesystems can all use extending filesystems.

Extended attributes

XFS, Ext4, and BtrFS allow you to create your own arbitrary file attributes. Because you're making up attributes, there's nothing built into your operating system to utilize them, but I use them as "tags" for files in much the same way I use EXIF data on photos. Developers might choose to use extended attributes to develop custom capabilities in applications.

There are two "namespaces" for attributes in XFS: user and root. When creating an attribute, you must add your attribute to one of these namespaces. To add an attribute to the root namespace, you must use the sudo command or be logged in as root.

Add an attribute

You can add an attribute to a file on an XFS filesystem with the attr or setfattr commands.

The attr command assumes the user namespace, so you only have to set (-s) a name for your attribute followed by a value (-V):

$ attr -s flavor -V vanilla example.txt
Attribute "flavor" set to a 7 byte value for example.txt:
vanilla

The setfattr command requires that you specify the target namespace:

$ setfattr --name user.flavor --value chocolate example.txtList extended file attributes

Use the attr or getfattr commands to see extended attributes you've added to a file. The attr command defaults to the user namespace and uses the -g option to get extended attributes:

$ attr -g flavor example.txt
Attribute "flavor" had a 9 byte value for example.txt:
chocolate

The getfattr command requires the namespace and name of the attribute:

$ getfattr --name user.flavor example.txt
# file: example.txt
user.flavor="chocolate"List all extended attributes

To see all extended attributes on a file, you can use attr -l:

$ attr -l example.txt
Attribute "md5sum" has a 32 byte value for example.txt
Attribute "flavor" has a 9 byte value for example.txt

Alternately, you can use getfattr -d:

$ getfattr -d example.txt
# file: example.txt
user.flavor="chocolate"
user.md5sum="969181e76237567018e14fe1448dfd11"

Any extended file attribute can be updated with attr or setfattr, just as if you were creating the attribute:

$ setfattr --name user.flavor --value strawberry example.txt

$ getfattr -d example.txt
# file: example.txt
user.flavor="strawberry"
user.md5sum="969181e76237567018e14fe1448dfd11"Attributes on other filesystems

The greatest risk when using extended attributes is forgetting that these attributes are specific to the filesystem they're on. That means when you copy a file from one drive or partition to another, the attributes are lost even if the target filesystem supports extended attributes.

To avoid losing extended attributes, you must use a tool that supports retaining them, such as the rsync command.

$ rsync --archive --xattrs ~/example.txt /tmp/

No matter what tool you use, if you transfer a file to a filesystem that doesn't know what to do with extended attributes, those attributes are dropped.

More Linux resources Linux commands cheat sheet Advanced Linux commands cheat sheet Free online course: RHEL technical overview Linux networking cheat sheet SELinux cheat sheet Linux common commands cheat sheet What are Linux containers? Our latest Linux articles Search for attributes

There aren't many mechanisms to interact with extended attributes, so the options for using the file attributes you've added are limited. I use extended attributes as a tagging mechanism, which allows me to associate files that have no obvious relation to one another. For instance, suppose I need a Creative Commons graphic for a project I'm working on. Assume I've had the foresight to add the extended attribute license to my collection of graphics. I could search my graphic folder with find and getfattr together:

find ~/Graphics/ -type f \
-exec getfattr \
--name user.license \
-m cc-by-sa {} \; 2>/dev/null

# file: /home/tux/Graphics/Linux/kde-eco-award.png
user.license="cc-by-sa"
user.md5sum="969181e76237567018e14fe1448dfd11"Secrets of your filesystem

Filesystems aren't generally something you're meant to notice. They're literally systems for defining a file. It's not the most exciting task a computer performs, and it's not something users are supposed to have to be concerned with. But some filesystems give you some fun, and safe, special abilities, and extended file attributes are a good example. Its use may be limited, but extended attributes are a unique way to add context to your data.

I use the open source XFS filesystem because of the subtle convenience of extended attributes. Extended attributes are a unique way to add context to my data.

Image by:

Internet Archive Book Images. Modified by Opensource.com. CC BY-SA 4.0

Linux Command line What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

What you need to know about site reliability engineering

opensource.com - Mon, 06/20/2022 - 15:00
What you need to know about site reliability engineering Robert Kimani Mon, 06/20/2022 - 03:00 Register or Login to like Register or Login to like

What is site reliability engineering? The creator of the first site reliability engineering (SRE) program, Benjamin Treynor Sloss at Google, described it this way:

Site reliability engineering is what happens when you ask a software engineer to design an operations team.

What does that mean? Unlike traditional system administrators, site reliability engineers (SREs) apply solid software engineering principles to their day-to-day work. For laypeople, a clearer definition might be:

Site reliability engineering is the discipline of building and supporting modern production systems at scale.

SREs are responsible for maximizing reliability, performance availability, latency, efficiency, monitoring, emergency response, change management, release planning, and capacity planning for both infrastructure and software. As applications and infrastructure grow more complex, SRE teams help ensure that these systems can evolve.

[ Read next: 8 reasons site reliability engineer is one of the most in-demand jobs in 2022 ]

What does an SRE organization do?

There are four primary responsibilities of an SRE organization:

  • Availability: SREs are responsible for the availability of the services they support. After all, if services are not available, end users' work is disrupted, which can cause serious damage to your organization's credibility.
     
  • Performance: A service needs to be not only available but also highly performant. For example, how useful is a website that takes 20 seconds to move from one page to another?
     
  • Incident management: SREs manage the response to unplanned disruptions that impact customers, such as outages, service degradation, or interruptions to business operations.
     
  • Monitoring: A foundational requirement for every SRE, monitoring involves collecting, processing, aggregating, and displaying real-time quantitative data about a system. This could include query counts and types, error counts and types, processing times, and server lifetimes.

Occasionally, release and capacity planning are also the responsibility of the SRE organization.

More open source career advice Open source cheat sheets Linux starter kit for developers 7 questions sysadmins should ask a potential employer before taking a job Resources for IT artchitects Cheat sheet: IT job interviews How do SREs maintain site reliability?

The SRE role is a diverse one, with many responsibilities. An SRE must be able to identify an issue quickly, troubleshoot, and mitigate it with minimal disruption to operations.

Here's a partial list of the tasks a typical SRE undertakes:

  • Writing code: An SRE is required to solve problems using software, whether they are a software engineer with an operations background or a system engineer with a development background.
     
  • Being on call: This is not the most attractive part of being an SRE, but it is essential.
     
  • Leading a war room: SREs facilitate discussions of strategy and execution during incident management.
     
  • Performing postmortems: This is an excellent tool to learn from an incident and identify processes that can be put in place to avoid future incidents.
     
  • Automating: SREs tend to get bored with manual steps. Automation not only saves time but reduces failures due to human errors. Spending some time on engineering by automating tasks can have a strong return on investment.
     
  • Implement best practices: SREs are well versed with distributed systems and web-scale architectures. They apply best practices in several areas of service management.
Designing an effective on-call system

An on-call management system streamlines the process of adding members of the SRE team into after-hours or weekend call schedules, assigning them equitable responsibility for managing alerts outside of traditional work hours or on holidays. In some cases, an organization might designate on-call SREs around the clock.

In the medical profession, on-call doctors don't have to be on site, but they do have to be prepared to show up and deal with emergencies anytime during their on-call shift. SRE professionals likewise use on-call schedules to make sure that someone's always there to respond to major bugs, capacity issues, or product downtime. If they can't fix the problem on their own, they're also responsible for escalating the issue. For SRE teams who run services for which customers expect 24/7/365, 99.999% uptime and availability, on-call staffing is especially critical.

There are two main kinds of on-call design structures that can be used when designing an on-call system, and they focus on domain expertise and ownership of a given service:

  • Single-team ownership model
  • Shared ownership model

In most cases, single-team ownership will be the better model.

The on-call SRE has multiple duties:

  • Protecting production systems: The SRE on call serves as a guardian to all production services they are required to support.
     
  • Responding to emergencies within acceptable time: Your organization may choose to have a service-level objective (SLO) for SRE response time. In most cases, anywhere between 5 to 15 minutes would be an acceptable response time. Automated monitoring and alerting solutions also empower SREs to respond immediately to any interruptions to service availability.
     
  • Involving team members and escalating issues: The on-call SRE is responsible for identifying and calling in the right team members to address specific problems.
     
  • Tackling non-emergent issues: In some organizations, a secondary on-call engineer is scheduled to handle non-emergencies, like email alerts.
     
  • Writing postmortems: As noted above, a good postmortem is a valuable tool for documenting and learning from significant incidents.
3 key tenets of an effective on-call management system A focus on engineering

SREs should be spending more time designing solutions than applying band-aids. A general guideline is for SREs to spend 50% of their time in engineering work, such as writing code and automating tasks. When an SRE is on-call, time should be split between about 25% of time managing incidents and 25% on operations duty.

Balanced workload

Being on call can quickly burn out an engineer if there are too many tickets to handle. If well-coordinated multi-region support is possible, such as a US-based team and an Asia-Pacific team, that arrangement can help limit the detrimental health effects of repeated night shifts. Otherwise, having six to eight SREs per site will help avoid exhaustion. At the same time, make sure all SREs are getting a turn being on call at least once or twice a quarter to avoid getting out of touch with production systems. Fair compensation for on-call work during overnights or holidays, such as additional hours off or cash awards, will also help SREs feel that their extra effort is appreciated.

Positive and safe environment

Clearly defined escalation and blameless postmortem procedures are absolutely necessary for SREs to be effective and productive. Established protocols are central to a robust incident management system. Postmortems must focus on root causes and prevention rather than individual and team actions. If you don't have a clear postmortem procedure in your organization, it is wise to start one immediately.

SRE best practices

This article covered some SRE basics and best practices for establishing and running an SRE on-call management system.

In future articles, I will look at other categories of best practices for SRE, the technologies involved, and the processes to support those technologies. By the end of this series, you'll know how to implement SRE best practices for designing, implementing, and supporting production systems.

More resources

Understand the basics and best practices for establishing and maintaining an SRE program in your organization.

Image by:

opensource.com

Careers DevOps What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Linus Torvalds Releases Linux 5.19-rc3 Father's Day Kernel

Phoronix - Mon, 06/20/2022 - 06:03
Linus Torvalds spent some of Father's Day today merging last minute pull requests for the week and issuing Linux 5.19-rc3 as the newest weekly test kernel...

GhostBSD 22.06.15 Brings Improved NVIDIA Driver Handling, Better Broadcom WiFi Detection

Phoronix - Sun, 06/19/2022 - 23:32
Out this weekend is a new version of GhostBSD, the desktop-focused operating system built atop a FreeBSD base and catering to the MATE desktop environment...

Pages