Open-source News

In OpenStack's 2021 User Survey, the majority of respondents said they use Kubernetes as the container orchestration or Platform-as-a-Service (PaaS) tool to manage their OpenStack applications. Simply put, OpenStack and Kubernetes work together to benefit sysadmins, developers, and users alike.

It's one thing to say that users rely on these two technologies, but I wanted to know how. I've found several typical use cases.

read more

EGroupware administration tips to meet your collaboration needs Heike Jurzik Tue, 03/08/2022 - 02:00 Up 1 reader likes this

In my previous article, I explained how to install and set up EGroupware on your own server. It also introduced the modules and external applications of the open source groupware solution. This article shows you how to take care of an existing installation and manage backups.

The Admin menu

The central point of administration is the Admin menu in the left sidebar. This is where you adjust EGroupware's general settings, take care of user accounts and passwords, change the home screen, view access logs, clear the web server cache, test the push server, and more.

 

In this area, you also configure users and groups, their access, and permissions. Right-click an entry to open a context menu with quick access to important configuration options. Please be extra careful with the User groups section. Each group has its own rights, so this is where you define access to specific data. Note that personal settings override those of the group, and the user's access rights are determined by what is set for the account and its groups.

Tip: You can limit access for users so that they only see what the resources really need—keep their workspaces clean and set sensible default settings. For example, hide those applications and functions which confuse less tech-savvy users.

More great content Free online course: RHEL technical overview Learn advanced Linux commands Download cheat sheets Find an open source alternative Explore open source resources Configure automatic upgrades

The whole EGroupware environment basically consists of several Docker containers working hand in hand. As a result, taking care of the installation is very convenient. Apart from delivering an optimally configured environment, the containers also make sure it's painless to upgrade single components as well as the entire system or even install additional applications.

EGroupware uses Watchtower to check for container updates. After the developers have published a new container image for EGroupware, Watchtower pulls it, gracefully shuts down the running container, and restarts the updated version with all necessary options. The check for updates runs every night at 4 a.m., but you can adjust the schedule by modifying the /etc/egroupware-docker/docker-compose.override.yml file.

Add your own mail server

Up until early 2021, EGroupware's email module was a mere mail client. These days the developers offer an additional mail server component—perfect for administrators who run EGroupware on-prem and want to run their own MTA. The manufacturer provides the package egroupware-mail for Debian and Debian-based distributions, which installs a container with Postfix and Dovecot, including an extension for push functionality in the EGroupware web client.

The entire administration of the mail server then runs via EGroupware's web interface. Every time the admin sets up a new user account, the corresponding mailboxes are generated automatically. The configuration for existing accounts happens in the Admin menu (User accounts). Right-click an entry and select Mail account to set up identities, signatures, IMAP folder structure, aliases, and forwards.

The Encryption tab allows you to upload an S/MIME certificate. Users must install the open source Mailvelope browser add-on to use PGP encryption. The private key remains with the owner (not with the EGroupware operator!), and users in the Mail module set up the public key.

 

SSL and 2FA

As noted in the first article, setting up SSL certificates is vital. At a bare minimum, admins should take the time to set up an SSL certificate for the reverse proxy (not the EGroupware webserver!)—even if EGroupware runs only on the local network.

EGroupware supports various authentication methods. The default is the local SQL database which stores the users' credentials. Alternatively, the groupware authenticates against LDAP, Active Directory, mail servers, and SAML 2/Shibboleth (Single Sign-On). Administrators can choose the preferred authentication in the setup dialog (www.example.com/egroupware/setup) immediately after the installation. In this context, they should restrict access to the setup dialog to local IPs.

Look at the Admin menu, Site configuration, tab Security. This is where you enable two-factor authentication (2FA), define rules for blocking users after incorrect password entries, and set up password policies.

 

Users of the Enterprise Line (EPL) version can configure a Web Application Firewall (Admin, Applications, EPL-Features, Firewall / 2FA). If only a small group of users should have access from external networks, you first define a rule that prevents access for everyone outside the local network. After that, create a new group and add all users allowed to log in from external networks. All firewall rules are processed one after the other. You can change their order with a drag-and-drop.

The firewall only handles interactive logins through the EGroupware web interface, but not synchronization with external clients, WebDAV access, or file shares. Check your firewall rules before saving them (button Test), ideally in an incognito tab or another web browser. Because the firewall only reacts to the logins, don't close the current session, so you remain logged in during testing.

Backup and restore

EGroupware offers help with creating backups, but you have to enable this—it's not part of the default settings. Go to Admin, DB backup and restore to adjust the configuration and access existing backups. In this section, you can define, amongst other things, a backup schedule and the number of copies you want to keep. Since this is a simple database dump (with a few extra config files), a backup doesn't need much space and time, so it's okay to keep 20 versions or more. Please note that if you rename a backup in this dialog, it no longer gets deleted during the automatic cleanup process.

You can download existing backups as Bzip2 archives to keep them safe on external storage media. Of course, you can upload the backups to another EGroupware server and restore them there. This even works on different Linux distributions.

 

When planning your backup strategy, you might want to consider the virtual file system in which EGroupware stores the internal file manager's data. Of course, those files and folders are not recorded in the database and are therefore not backed up automatically. You can save those files if you tick the Check to backup and restore the files directory... box—this may take up a lot of disk space, though.

For a full backup, you should also take care of the /var/lib/egroupware directory on the EGroupware server with the backup software of your choice. This has one significant advantage: In addition to the file manager's data, you preserve the header file (with the database passwords), files from external applications (e.g., from Guacamole, Rocket.Chat, and Collabora Online), logs from the installation, etc.

Close collaboration

Taking care of an EGroupware installation is not particularly difficult, but it needs to be done. As an admin, you should familiarize yourself with the software and its configuration. Luckily, the developers follow the KISS principle (Keep it sweet and simple)—all modules collaborate nicely, and upgrades are thoroughly tested before they are released.

If you run into trouble, the community forum is there to help. This forum is also where you hear about upcoming changes and other news.

Familiarize yourself with these tips and tricks to optimize this open source groupware solution for your team.

Image by:

Opensource.com

Alternatives 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.

Editor’s note: Paul Cormier, Red Hat's president and chief executive officer, shared the following email with Red Hat associates today.

All, 

The latest change to be proposed for the Fedora 37 release later this year is encouraging package maintainers to drop unused 32-bit x86 (i686) packages...

Linux distros patch 'Dirty Pipe' make-me-root kernel bug  The Register

PS4/Switch/Linux Release: pEMU 5.1 (NES/SNES/Arcade emulator suite)  Wololo.net

1. 'Dirty Pipe' Linux vulnerability discovered  ZDNet
2. Serious 'Dirty Pipe' Bug Patched in Linux Kernel  Duo Security
3. New Linux bug gives root on all major distros, exploit released  BleepingComputer
4. 'Dirty Pipe' Permission Flaw Patched in Linux Kernel  GovInfoSecurity.com
5. 'Dirty Pipe' Linux vulnerability allows an attacker to overwrite data  SiliconANGLE News
6. View Full Coverage on Google News

New Linux bug gives root on all major distros, exploit released  BleepingComputer

Open-Source AMD Radeon Linux Graphics In Great Shape For Workstations, Handily Beating Proprietary Driver  Phoronix

With SPECViewPerf 2020 finally released for Linux I was curious to see how AMD's open-source "RadeonSI" Gallium3D driver within Mesa would compare to the performance offered by AMD's proprietary OpenGL Linux driver. After all, that longstanding proprietary driver, which is distributed as part of their Radeon Software for Linux driver package, has code in common with their Windows OpenGL driver and has previously been talked up as the preferred choice for workstation customers. Well, the latest open-source driver stack was outright kicking mud at that legacy binary blob for SPECViewPerf 2020 as well as the ParaView workstation visualization software.

Decentralized Identity Solution Market Next Big Thing : Major Giants Linux, BlocWatch, BizSecure  Digital Journal

How to Run Android Apps and Games on Linux  BollyInside

After a week delay in processing of the monthly Steam Survey data, the Steam Survey results for February 2022 are in! Yes, the much anticipated Steam Deck did begin shipping in February, but at the tail-end and in limited quantities, so don't expect any big surprises.....

Steam Survey Results For February 2022 Put Linux Right Above 1.0%  Phoronix

The 15 Best Educational Linux Apps for Students  MUO - MakeUseOf

4 Best Linux Open source Firewall for Cyber Security - 2022  Linux Shout

Firefox 98 Set For Release With Dialog Element, Still Working On Wayland Support  Phoronix

Mozilla Firefox 98.0 binaries have hit the web today ahead of the formal release announcement tomorrow. There are various improvements in this latest monthly update to the Firefox web browser while its Wayland support for the Linux desktop remains ongoing...

Go From Linux Rookie to Expert for $69  PCMag

Introduction

It has been estimated that Free and Open Source Software (FOSS) constitutes 70-90% of any given piece of modern software solutions. FOSS is an increasingly vital resource in nearly all industries, public and private sectors, among tech and non-tech companies alike. Therefore, ensuring the health and security of FOSS is critical to the future of nearly all industries in the modern economy. 

In March of 2022, The Linux Foundation, in partnership with the Laboratory for Innovation Science at Harvard (LISH), released the final results of an ongoing study, “Census II of Free and Open Source Software – Application Libraries.” This follows the preliminary release, “Vulnerabilities in the Core,’ a Preliminary Report and Census II of Open Source Software” in February 2020 and now identifies more than one thousand of the most widely deployed open source application libraries found from scans of commercial and enterprise applications. This study informs what open source projects are commonly used in applications warrant proactive analysis of operations and security support. 

Download Report

The completed report from the Census II study identifies the most commonly used free and open source software (FOSS) components in production applications. It begins to examine the components’ open source communities, which can inform actions to sustain FOSS’s long-term security and health. The stated objectives were:

• Identify the most commonly used free and open source software components in production applications. 

• Examine for potential vulnerabilities in these projects due to:

• Widespread use of outdated versions; 
• Understaffed projects

• Use this information to prioritize investments and other resources needed to support the security and health of FOSS

What did the Linux Foundation and Harvard learn from the Census II study?

The study was the first to analyze the security risks of open source software used in production applications. It is in contrast to the earlier Census I study that primarily relied on Debian’s public repository package data and factors that would identify the profile of each package as a potential security risk.

To better understand the commonality, distribution, and usage of open source software within organizations, the study used software composition analysis (SCA) data supplied by Snyk,  Synopsys, and FOSSA. SCA is the process of automating visibility into any software, and these tools are often used for risk management, security, and license compliance. SCA solution providers routinely scan codebases used by private and public sector organizations. The scans and audits provide a deep insight into what open source is being used in production applications.

With this data, the study created a baseline and unique identifiers for common packages and software components used by large organizations, which were then tied to a specific project. This baselining effort allowed the study to identify which packages and components were the most widely deployed. 

Census II includes eight rankings of the 500 most used FOSS packages among those reported in the private usage data contributed by SCA partners. The analysis performed is based on 500,000 observations of FOSS usage in 2020.

These include different slices of the data based on versions, structure, and packaging system.  For example, this research enables identification of the top 10 version-agnostic packages available on the npm package manager that were called directly in applications:

• lodash
• reach
• axios
• debug
• @babel/core
• express
• semver
• uuid
• react-dom
• jquery

Other slices of the data examined in the study include versioned versus version agnostic, npm versus non-npm, direct versus indirect (and direct) packages. All eight top 500 lists are included in an open data repository on Data.World. 

Observations and analysis of these specific metrics led the study to come to certain conclusions. These were:

• Software components need to be named in a standardized schema for security strategies to be effective. The study determined that a lack of naming conventions used by packages and components across repositories was highly inconsistent. Thus, any ongoing effort to create software security and transparency strategies without industry participation would have limited effect and slow such efforts. 
• The complexities associated with package versioning. In addition to the need for standardized naming schema mentioned above, Software Bill of Materials (SBOM) guidance will need to reflect versioning information consistent with the public “main” repository for that package, rather than private repositories. Many of the versions that our data partners reported did not exist in the public repositories for those packages because developers maintained internal forks of the code.
• Developer accounts must be secured. The analysis of the software packages with the highest levels of usage found that many were hosted on individual (personal) developer accounts. Lax developer security practices have considerable implications for large organizations that use these software packages because they have fewer protections and less granularity of associated permissions. The OpenSSF encourages MFA tokens or organizational accounts to achieve greater account security.
• Legacy open source is pervasive in commercial solutions. Many production applications are being deployed that incorporate legacy open source packages. This prevalence of legacy packages is an issue as they are often no longer supported or maintained by the developers or have known security vulnerabilities. They often lack updates for known security issues both in their codebase or in the codebase of dependencies they require to operate. 
• Apache log4j, version 1.x, for example, was ten times more prevalent than log4j 2.x (the version requiring recent remediation), and 1.x still has known unpatched disclosed vulnerabilities because the software was declared end-of-life (EOL) in 2015.
• Legacy packages present a vulnerability to the companies deploying them in their environments — it means they will need to know what open source packages they have deployed and where to maintain and update these codebases over time.
• The prevalence of “supercoders” in the FOSS community. Much of the most widely used FOSS is developed by only a handful of contributors – results in one dataset show that 136 developers were responsible for more than 80% of the lines of code added to the top 50 packages. Additionally, as stated in the Census II preliminary results in 2020, project atrophy and contributor abandonment is a known issue with legacy open source software. The number of developer contributors who work on projects to ensure updates for feature improvements, security, and stability decreases over time as they prioritize other software development work in their professional lives or decide to leave the project for any number of reasons. Therefore, it is much more likely that these communities may face challenges without sufficient developers to act as maintainers as time goes by.

What resources exist to better understand and mitigate potential problem areas in Open Source Software development? 

The Linux Foundation’s community and other open source projects initiatives offer important standards, tooling, and guidance that will help organizations and the overall open source community gain better insight into and directly address potential issues in their software supply 

chain.

Software Bill of Materials: Adopt the ISO/IEC 5962:2021 SPDX SBOM Standard

An actionable recommendation from Census II is to adopt Software Bill of Materials (SBOM) within your organization. SBOMs serve as a record that delineates the composition of software systems. Software Package Data Exchange (SPDX) is an open international standard for communicating SBOM information that supports accurate identification of software components, explicit mapping of relationships between components, and the association of security and licensing information with each component. 

Many enterprises concerned about software security are making SBOMs a cornerstone of their cybersecurity strategy. The Linux Foundation recently published a separate study on SBOM readiness within organizations, The State of Software Bill of Materials (SBOM) and Cybersecurity Readiness. The report offers fresh insight into the state of SBOM readiness by enterprises across the globe, identifying patterns from innovators, early adopters, and procrastinators. 

Differentiated by region and revenue, these organizations identified current SBOM production and consumption levels and the motivations and challenges regarding their present and future adoption. This report is for organizations looking to better understand SBOMs as an important tool in securing software supply chains and why it is now time to adopt them.

Take the free training on secure software development 

The Open Source Security Foundation (OpenSSF) has developed a trio of free courses on how to develop secure software. These courses are part of the Secure Software Development Fundamentals Professional Certificate program.  There’s a fee if you want to try to earn a certificate (to prove that you learned the material). However, if you just want to learn the material without earning a certificate, that’s free; simply audit the course. You can also start for free and upgrade later if you pay within the upgrade deadline. All three courses are available on the edX platform.

The courses included in the program are:

• Secure Software Development: Requirements, Design, and Reuse (LFD104x)
• Secure Software Development: Implementation (LFD105x)
• Secure Software Development: Verification and More Specialized Topics (LFD106x)

Focus on building security best practices into your open source projects

The OpenSSF develops and hosts its Best Practices badging program for open source software developers. This initiative was one of the first outputs produced as a result of the Census I, completed in 2015. Since then, over 4,000 open source software projects have engaged, started, or completed obtaining a  Best Practices Badge.

Projects that conform to OpenSSF best practices can display a badge on their GitHub page or their own web pages and other material. In contrast, consumers of the badge can quickly assess which FLOSS projects are following best practices and, as a result, are more likely to produce higher-quality and secure software. Additionally, a Badge API exists that allows developers and organizations to query the practice score of a specific project, such as Silver, Gold, and Passing. This means any organization can do an API check within their workflow to check against the open source packages they’re using and see if that project’s community has obtained a badge.

More information on the OpenSSF Best Practices Badging program, including background and criteria, is available on GitHub. The projects page shows participating projects and supports queries (such as a list of projects that have a passing badge). Project statistics and criteria statistics are available. 

Understand the vulnerability vectors of your software supply chain

In addition to reviewing the Census II findings, we encourage you to read the Linux Foundation’s Open Source Supply Chain Security Whitepaper. This publication explores vulnerabilities in the open source software ecosystem through historical examples of weaknesses in known infrastructure components (such as lax developer security practices and end-user behavior, poorly secured dependency package repositories, package managers, and incomplete vulnerability databases). It provides a set of recommendations for organizations to navigate potential problem areas. 

Conclusion

The Census II study shows that even the most widely deployed open source software packages can have issues with security practices, developer engagement, contributor exodus, and code abandonment. Therefore, open source projects require supporting toolsets, infrastructure, staffing, and proper governance to act as a stable and healthy upstream project for your organization. 

Subscribe to LF Research

The post A Summary of Census II: Open Source Software Application Libraries the World Depends On appeared first on Linux Foundation.