fidzu : Fedora

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. It also contains updates for CPE (Community Platform Engineering) Team as the CPE initiatives are in most cases tied to I&R work.

We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 22 - 26 July 2024

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It's responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra

• In progress:
  • rhel7 EOL
  • Migration of registry.fedoraproject.org to quay.io
  • add monitoring for dnf countme
  • Replace Nagios with Zabbix in Fedora Infrastructure
  • notifications do not notify
  • PDC retirement
  • Move from iptables to firewalld
  • Update compose hosts to get latest pungi release (4.6.0)
  • Deploy new sign hardware/software
  • Commits don't end up on the scm-commits list
  • Create monitoring tool for rabbitmq certificates
  • Private mirror check-in with mirrormanager fails
  • rhel9 adoption
  • How do I set up FAS login for discussion.stg.fedoraproject.org?
  • Private mirror check-in with mirrormanager fails
  • EPEL minor version archive repos in MirrorManager
  • Cleaning script for communishift
  • Grant additional permissions to the fedimg AWS role
  • fedmsg -> fedora-messaging migration tracker
  • rhel7 EOL - github2fedmsg
  • rhel7 EOL - Fedimg
  • COPR cannot pull git repo from fedorapeople
  • Searching mailing list archives does not work
  • Feature / Change request: make the Fedora bugzilla more accessible
  • AWS: support creating S3 buckets
  • AWS: Support adding elastic IPs
  • Moderating mailing list viewing message shows "This held message has been lost."
  • release-monitoring.org crawlers seem to not be running since ~June 26
  • buildhw-a64 01,02,19,20,21,22,23,24 not booting
  • STG Bugzilla doesn't send messages to STG fedora-messaging
  • Support allocation dedicated hosts for Testing Farm
  • vmhost-x86-copr01.rdu-cc.fedoraproject.org DOWN
  • Can't login to pagure.io/src.fedoraproject.org/COPR
  • OIDC request for Konflux cluster for fedora
• Done:
  • Request for new FAS group: miracle-sig
  • Login issues on site, missing download links, others…
  • Still CC'ed in Chromium security bugs even though I'm not in points of contact anymore
  • pulling from fedora container registry is really slow
  • Need to compress logs on log01
  • okeamah spam
  • Unable to waive gating failures
  • Creating a new group called @MavrykDynamics

CentOS Infra including CentOS CI

• In progress:
  • Decommission old dedicated hardware used for c7/c8s builds
  • HDD issue on internal storage server used for Stream
• Done:
  • Inherit AutoSD release tag instead of testing for automotive9s-packages-main-el9s-build

Release Engineering

• In progress:
  • Packages that fail to build SRPM are not reported during the mass rebuild bugzillas
  • i686 builders need to use 32-bit inode numbers
  • When orphaning packages, keep the original owner as co-maintainer
  • Use an automated script to control checksums of compose images
  • Create an ansible playbook to do the mass-branching
  • Package retirements are broken in rawhide
  • Implement checks on package retirements
  • Update bootloader components assignee to "Bootloader Engineering Team"for Improved collaboration
  • Cleaning old stuff from koji composes directories
  • Untag containers-common-0.57.1-6.fc40
  • Renaming distribution media for Fedora Server
  • Remove PDC from package retirement process
  • Fix tokens for ftbfs_weekly_reminder. Script
  • Fedora-34-Beta .composeinfo file
  • Publish x86_64/aarch64 containers to the new AWS container repo
  • Update block_retired.py to use bodhi api
  • orphan-all-packages.py should remove bugzilla_contact entries from fedora-scm-requests as well
  • unmaintained bot account: dummy-test-package-gloster gating pipeline tests broken
  • Drop modularity from EPEL8.
  • Fedora 41 Mass Rebuild Tracker
  • Some (?) retired packages not actually getting retired since ~2 days ago
  • Missing i686 package
  • Retire golang-github-src-d-gcfg
  • Investigate and untag packages that failed gating but were merged in via mass rebuild
• Done:
  • Fedora 41 Mass Rebuild
  • Retire EPEL 8 Next
  • EPEL 8 buildroot broken (no platform-python)
  • Unretire 0install
  • untag shadow-utils-4.15.1-8.fc41
  • Untag firewalld 2.2.0-2.fc41
  • Most wiggle updates missing from Bodhi
  • Untag NetworkManager-openvpn-1.12.0-1.fc41 and NetworkManager-openvpn-1.12.0-1.eln141
  • Stalled EPEL Package: physfs

CPE Initiatives

EPEL

Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux (SL) and Oracle Linux (OL).

Updates

• Sync EPEL docs framework files with latest Fedora docs template
• Removed EPEL 7 and EPEL 8 Next from EPEL docs
• Completed EPEL 8 Next retirement
• Reviewed in-progress EPEL EOL documentation

Community Design

CPE has few members that are working as part of Community Design Team. This team is working on anything related to design in Fedora Community.

Updates

• F42 wallpaper theme is Quest!
• Podman desktop: working on refining page layouts and integration with other apps.

ARC Investigations

The ARC (which is a subset of the CPE team) investigates possible initiatives that CPE might take on.

Updates

• Dist Git Move
  • Ryan Lerch worked on deploying Forgejo in the Fedora Infrastructure OpenShift
    • https://forgejoroute-communishift-forgejo.apps.fedora.cj14.p1.openshiftapps.com/
  • Akashdeep Dhar has completed with around 80% with the GitLab investigation
  • Tomas Hrcka has been in touch with the QA team on Monday during their
    • frantisekz from the QA team would be the point of contact for us to help with the Dist Git Move ARC investigation process
    • The QA team would provide us with the documentation that would help us with the investigation that involves Dist Git and Bugzilla
    • Limited access would be provided to those who proposed the user stories as well as those who request for the same to help with the ARC investigation
  • David Kirwan to work on the GitLab deployment on Fedora Infrastructure OpenShift
    • No proper deployment would be made for the ephemeral GitLab
    • Deployment will be torn down after around a couple of weeks from Flock announcement
    • GitLab deployment would be announced about during Flock To Fedora
  • FESCO nominated Stephen Gallagher who would be the point of contact from their end to help with the Dist Git Move ARC investigation
    • Tomas Hrcka plans to connect with Stephen Gallagher and reach back to the team with the inputs/outputs
    • Akashdeep Dhar proposed to use the #fedora-arc:fedora.im channel instead for a more asynchronous communication

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

The post Infra and RelEng Update - Week 30 2024 appeared first on Fedora Community Blog.

26 Jul 2024 10:00am GMT

Fedora test days are events where anyone can help make certain that changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you've never contributed to Fedora before, this is a perfect way to get started.

There are two upcoming test periods in the next week covering two topics:

• Sunday 28 July through Sunday 04 August, is to test Kernel 6.10.
• Monday 29 July through Wed 31 July , is to test Podman 5.2

Come and test with us to make Fedora 41 even better. Read more below on how to do it.

Kernel 6.10 Test Week

The kernel team is working on final integration for Linux kernel 6.10. This recently released kernel version will be the release Kernel for Fedora 41. As a result, the Fedora Linux kernel and QA teams have organized a test week from Sunday, July 28, 2024 to Sunday, August 04, 2024.

The wiki page contains links to the test images you'll need to participate. The results can be submitted in the test day app.

Podman 5.2 Test Days

Podman is a daemon-less, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images. It provides a command line interface (CLI) familiar to anyone who has used the Docker Container Engine. As part of a recent discussion, the Rawhide Test Day efforts, and Podman Container Engine Team's collaborative efforts, we will hold test days for this minor Podman Release.

During these test days, on Monday 29 July through Wed 31 July, the focus will be on testing the changes that will be coming in Fedora 41 (Rawhide) as we move ahead with Podman 5.1. This is an opportunity for anyone to learn and interact with the Podman Community and container tools in general.

The wiki page helps the testers know and understand the scope of the test days. The Test day app helps the testers submit the results once they have tried the test cases.

How do test days work?

A test day/week is an event where anyone can help make sure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you've never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to download test materials (which include some large files) and then read and follow directions step by step.

Detailed information about all the test days is available on the wiki pages mentioned above. If you're available on or around the days of the events, please do some testing and report your results. All the test day pages receive some final touches which complete about 24 hrs before the test day begins. We urge you to be patient about resources that are, in most cases, uploaded hours before the test day starts.

Come and test with us to make the upcoming Fedora Linux 41 even better

26 Jul 2024 8:00am GMT

25 Jul 2024 6:19pm GMT

24 Jul 2024 9:24pm GMT

In the realm of battery chargers, XTAR has carved a niche for itself by consistently delivering innovative and reliable products. The XTAR MiniMixer MX4 Charger is a testament to this legacy, offering versatility and advanced technology to meet the needs of diverse users. This article explores the features, benefits, technical specifications, and user experiences with the MiniMixer MX4, providing a detailed overview of why this charger stands out in the market.

Introduction to XTAR and the MiniMixer MX4

XTAR is renowned for its focus on quality and innovation in the battery charger industry. The MiniMixer MX4, a multi-functional charger, exemplifies the company's commitment to creating products that cater to both amateur and professional users. Designed to charge a variety of batteries, the MX4 is especially popular among photographers, outdoor enthusiasts, and gadget users who require a reliable and versatile charging solution.

Key Features of the MiniMixer MX4 Charger

1. Compatibility with Multiple Battery Types
   One of the standout features of the MX4 is its ability to charge different types of batteries, including Li-ion, Ni-MH, Ni-CD, and LifePO4. This flexibility makes it an essential tool for users with diverse battery needs, eliminating the need for multiple chargers.
2. Smart Battery Recognition
   The MX4 is equipped with smart battery recognition technology, which automatically identifies the type and capacity of the inserted battery. This feature ensures optimal charging by adjusting the current and voltage settings, thus prolonging battery life and enhancing safety.
3. Dual Charging Modes
   The charger offers two distinct modes: Standard and LifePO4. The LifePO4 mode is specifically designed for lithium iron phosphate batteries, providing a tailored charging process that ensures safety and efficiency. Users can easily switch between modes depending on their needs.
4. Advanced Safety Features
   Safety is a priority for XTAR, and the MX4 includes multiple protection mechanisms such as overcharge protection, short-circuit protection, and reverse polarity protection. These features safeguard both the charger and the batteries, providing peace of mind to users.

Benefits and Applications

The versatility of the MX4 makes it suitable for various applications. For photographers, it ensures that camera batteries are always ready for action. Outdoor enthusiasts appreciate its ability to charge batteries for flashlights, radios, and other essential gear. Moreover, the smart charging technology is crucial for maintaining the health and longevity of batteries, which is particularly important for expensive or hard-to-replace battery types.

Technical Specifications and Design

The MX4 charger features a compact and user-friendly design, making it suitable for both travel and home use. It supports a wide input voltage range of 100-240V, which is ideal for international usage. The charger utilizes a USB Type-C input for power, offering convenience and compatibility with modern devices. LED indicators provide clear updates on charging status, allowing for straightforward monitoring without the need for a more complex display. This design balances functionality with ease of use, catering to a broad range of users.

Comparison with Other Chargers

In comparison to other chargers on the market, the MX4 stands out due to its comprehensive feature set and competitive pricing. While some chargers offer similar capabilities, the MX4's combination of smart technology, safety features, and multi-battery compatibility positions it as a leader in its category. It offers excellent value for money, especially for users who require a versatile and reliable charging solution.

User Reviews and Testimonials

User feedback on the MX4 is overwhelmingly positive, with many praising its reliability and ease of use. Common highlights include the charger's ability to quickly and efficiently charge a wide range of batteries, as well as its intuitive design. However, some users have noted that the charger can be slightly bulky for those with limited space, although this is a minor drawback given its overall functionality.

Unboxing

During the unboxing of the XTAR MiniMixer MX4 Charger, I tested it with XTAR 14500 and 18650 batteries. The charger's solid construction was immediately apparent, and the setup was intuitive. The batteries fit snugly into the slots, and the LED indicators provided clear status updates, distinguishing between charging, full charge, and error states. This hands-on experience highlighted the charger's practicality and ease of use. You can watch the full unboxing experience down here.

Conclusion

The XTAR MiniMixer MX4 Charger is a versatile and reliable solution for charging a variety of batteries. Its advanced features, user-friendly design, and strong safety mechanisms make it a standout choice for both professional and amateur users. Whether you are a photographer, outdoor enthusiast, or just someone with multiple battery-powered devices, the MX4 is an investment that ensures your batteries are always charged and ready to go.

Looking to keep your rechargeable batteries topped up? The XTAR MiniMixer MX4 Charger might be the perfect solution! This nifty gadget can be found on the official XTAR website https://www.xtar.cc/product/xtar-minimixer-mx4-charger.html and from an authorized seller on Shopee Malaysia https://s.shopee.com.my/30TpyMEguR.

The post XTAR MiniMixer MX4 Charger: A Comprehensive Review appeared first on HamRadio.My - Ham Radio, Fun Facts, Open Source Software, Tech Insights, Product Reviews by 9M2PJU.

24 Jul 2024 4:10pm GMT

When all you have is a hammer, everything looks like a nail. In much the same way, when your background is in organization, everything looks like a process need. While open source projects do need process and organization (otherwise I wouldn't have written a book!), the amount of process needed grows with the size of the community.

Too often, I've seen (including from myself) community leaders build out way more process than is necessary. This isn't necessarily harmful, but it does distract from getting more meaningful work done. It's a way to look busy without accomplishing anything. Process can be the scaffolding to build and grow community, but if you have scaffolding you'll never use, it was a waste to set it up.

I've recently found myself tempted to re-organize some of the governance documentation for GUAC. Not improving or streamlining processes, just shuffling it into a different place. But while I have no doubt that I am right in my opinion, the current state is sufficient. I could put the work in to reorganize the content and convince the maintainers to approve my pull requests. That seems like a waste of everyone's time, when I could instead be trying to recruit new contributors, write blog posts, find reference users, and generally just do the hard work that pays off.

In a previous role, my manager and I were working on a corporate style guide for the marketing team to use. I asked her "should I put this in Jira or would that just be a coat of paint?" In other words: would the effort to set up a board to track the work be worth the coordination benefit we'd get?

Finding the right level of organization

There are a few things you need to have right away. You need a:

• basic governance structure so you know who makes decisions and how
• code of conduct
• process for removing people

Once you have those things, get building! Wait to solve problems until you have them. You can't know for sure which problems you'll have first anyway. Communities are not code: you don't have to anticipate every possible exception.

People will typically follow processes that they 1. know about and 2. understand. So if you can't make the case for why the process is necessary right now, you probably don't need it. In Program Management for Open Source Projects, I wrote about looking for the places people cut corners on a process to figure out where you need to improve it. Improvement can also be "remove the process." If you discover you've been over-enthusiastic about process creation, it's not to late to take a step back.

One guideline I like to use to check myself: whose life does this make easier? If the answer is only "mine!", then it's probably not worth imposing on the rest of the community.

Finding the right level of organization is a trial-and-error process. Even if you've done it before, no two communities are exactly alike. And, if you're lucky, once you've found the right level, the community will grow and you'll have to adjust again.

This post's featured photo by Alvaro Reyes on Unsplash

The post A veneer of organization appeared first on Duck Alignment Academy.

24 Jul 2024 12:00pm GMT

24 Jul 2024 5:07am GMT

23 Jul 2024 8:00pm GMT

23 Jul 2024 1:52pm GMT

Exciting News for Malaysian Ham Radio Enthusiasts!

We are thrilled to introduce a new and efficient tool designed specifically for searching Malaysian amateur radio callsigns. Whether you're a seasoned operator or just starting out, this tool simplifies the process of finding detailed information about callsigns in Malaysia.

About the Tool

Our Callsign Search Tool provides a user-friendly interface where you can easily search for amateur radio callsigns. Built with Node.js, it ensures fast and reliable performance. The tool is accessible, straightforward, and easy to use for all users.

Features:

• Quick Searches: Find callsign information quickly with our efficient search functionality.
• Simple Interface: The tool features a clean and easy-to-navigate design.
• Free Access: No need for special configurations-just visit the link and start searching!

Why Use This Tool?

• Accuracy: Our tool pulls data from reliable sources to provide you with accurate information.
• Convenience: Access it from anywhere with an internet connection.
• Support: Designed with the needs of Malaysian amateur radio operators in mind.

Technical Details

The tool is hosted on a Node.js server and runs on a Raspberry Pi, providing an efficient and energy-saving solution. It is securely accessible via the internet thanks to Cloudflare's tunnel technology, which ensures smooth and secure operation. This setup allows us to serve the tool to users efficiently and securely, providing reliable access at all times.

Get Started Now!

Visit https://callsign.hamradio.my/ to start searching for Malaysian amateur radio callsigns. We hope this tool becomes a valuable resource for the ham radio community!ateur radio callsigns. We hope this tool becomes a valuable resource for the ham radio community!

The post Discover the New Tool for Malaysian Amateur Radio Callsign Searches appeared first on HamRadio.My - Ham Radio, Fun Facts, Open Source Software, Tech Insights, Product Reviews by 9M2PJU.

23 Jul 2024 1:55am GMT

Introduction

The TIDRADIO TD H8, a popular model among radio enthusiasts, has just become even more versatile and user-friendly thanks to a custom firmware developed by Marcus, known in the community as Nicsure. This custom firmware builds upon the latest official firmware version 230923, introducing a range of new features designed to enhance the device's functionality and user experience.

What's New in the Custom Firmware?

Nicsure's custom firmware introduces several significant improvements and new features:

1. Three Types of Signal Bars:
   • Solid Signal Bar: A continuous bar that provides a straightforward and easy-to-read display of signal strength.
   • Segmented Signal Bar: This version breaks the signal bar into segments, offering a more detailed representation of signal strength fluctuations.
   • S Meter Pro: A professional-grade signal meter that provides precise and detailed signal strength readings, ideal for advanced users who need more accurate information.
2. Two Types of Battery Indicators:
   • Percentage Indicator: Displays the battery level as a percentage, offering a clear and precise understanding of remaining battery life.
   • Icon Indicator: A traditional battery icon that changes to show different levels of battery charge, providing a quick visual reference.
3. Frequency Adjustment:
   • Users can fine-tune their frequency settings within a range of +64 MHz to -200 MHz, ensuring optimal performance and better communication clarity.
4. Signal Bar Calibration:
   • Users can now calibrate the signal bar to match their specific requirements and preferences, enhancing the accuracy and usefulness of the signal strength display.

How to Install the Custom Firmware

Installing the custom firmware on your TIDRADIO TD H8 is a straightforward process. To get started, follow these steps:

1. Download the Firmware:
   • Visit the official GitHub repository at Nicsure's TD-H8 Engineering to download the custom firmware files.
2. Prepare Your Device:
   • Ensure your TD H8 is fully charged and connected to your computer via programming cable.
3. Install the Firmware:
   • Follow the detailed installation instructions provided in the repository. This typically involves running a firmware update tool and selecting the custom firmware file.
4. Restart and Enjoy:
   • Once the installation is complete, restart your device and explore the new features and enhancements.

Why Choose Nicsure's Custom Firmware?

Nicsure's custom firmware is a testament to the power of community-driven innovation. By addressing the needs and preferences of radio enthusiasts, Marcus has created a more versatile and user-friendly firmware that adds significant value to the TIDRADIO TD H8.

Whether you're a seasoned radio operator or a newcomer to the hobby, this custom firmware offers improvements that can enhance your experience. The added features provide greater control over your device's performance, allowing you to tailor it to your specific needs.

Conclusion

The TIDRADIO TD H8 is already a reliable and popular choice among radio enthusiasts, and with Nicsure's custom firmware, it becomes even more powerful. By adding new signal bars, battery indicators, frequency adjustment, and calibration options, this firmware enhances both the functionality and user experience of the TD H8.

To explore these exciting new features, download the custom firmware from Nicsure's GitHub repository and follow the installation instructions. Unlock the full potential of your TIDRADIO TD H8 and take your radio communication to the next level.

For more information and to download the firmware, visit Nicsure's TD-H8 Engineering on GitHub.

The post Unlocking the Potential of the TIDRADIO TD H8: Custom Firmware by Nicsure appeared first on HamRadio.My - Ham Radio, Fun Facts, Open Source Software, Tech Insights, Product Reviews by 9M2PJU.

22 Jul 2024 5:58pm GMT

Flashlights are essential tools for many people, whether used for everyday tasks, outdoor adventures, or emergency situations. However, the vast range of options available can make choosing the right flashlight a daunting task. This guide aims to demystify the process by providing an in-depth look at the key factors to consider when buying a flashlight, including its intended use, essential features, battery types, brightness metrics, and additional features.

1. Understanding the Purpose of Your Flashlight

The first and most crucial step in choosing a flashlight is determining its primary use. Different scenarios require different types of flashlights, and understanding your needs will help you select the most appropriate model.

• Everyday Carry (EDC): For everyday use, you need a flashlight that is compact, lightweight, and easy to carry. EDC flashlights are designed for convenience and practicality, often fitting in a pocket or a small bag. They should be reliable and sufficient for tasks like reading in the dark, walking the dog, or finding something that has dropped.
• Outdoor/Survival: If you're an outdoor enthusiast or someone preparing for survival situations, you need a flashlight that is durable, water-resistant, and has a long battery life. Outdoor and survival flashlights are built to withstand harsh conditions and are often equipped with features like a rugged exterior, shock resistance, and multiple brightness settings. They are useful for camping, hiking, and navigating through rough terrains.
• Emergency Preparedness: For emergency situations, reliability is key. An emergency flashlight should be easy to use, durable, and have a long shelf life. It's important to choose a flashlight that is dependable when you need it most, whether during power outages, natural disasters, or other unforeseen events.
• Tactical: Tactical flashlights are designed for use by law enforcement, military personnel, and other professionals. They are characterized by their high brightness, robust construction, and additional features like strobe modes. Tactical flashlights are used for self-defense, signaling, and navigating in dark or dangerous situations.
• Work/Professional: Professionals who need a flashlight for work, such as mechanics, electricians, or emergency responders, require a model that is bright, durable, and tailored to specific tasks. Features such as adjustable beams, magnetic bases, or hands-free options can be beneficial in professional settings.

2. Key Metrics to Consider

When evaluating flashlights, several metrics can help you determine their performance and suitability for your needs. Understanding these metrics will guide you in choosing a flashlight that meets your specific requirements.

• Lumens: Lumens measure the total amount of visible light emitted by the flashlight. Higher lumen values indicate a brighter light. The right lumen output depends on your intended use:
• Low (50-200 lumens): Suitable for tasks that require close-up illumination, such as reading or finding items in a dimly lit room.
• Medium (200-500 lumens): Ideal for general use and short-range illumination, including walking or light outdoor activities.
• High (500+ lumens): Best for long-distance visibility and high-intensity tasks, such as search and rescue or tactical operations.
• Candela: Candela measures the intensity of light in a specific direction, reflecting how concentrated or focused the beam is. Higher candela values indicate a more intense and focused beam, which is useful for tasks requiring long-range visibility.
• Low (1,000-5,000 candela): Provides diffuse light suitable for close-range tasks.
• Medium (5,000-15,000 candela): Offers a focused beam with moderate distance, suitable for general use and moderate range applications.
• High (15,000+ candela): Delivers a high-intensity, long-range beam, ideal for search and rescue or tactical scenarios.
• Beam Distance: Beam distance refers to how far the light travels before it becomes ineffective. This metric is usually measured in meters and is important for tasks that require long-range visibility. The beam distance can vary based on the flashlight's brightness and beam focus.

3. Selecting the Right Battery Type

The type of battery a flashlight uses can significantly affect its performance, runtime, and overall cost. Here are the common battery options available:

• Alkaline Batteries: Alkaline batteries are widely available and relatively inexpensive. They are suitable for general use but are not rechargeable. Over time, they may lose capacity, leading to decreased performance. Alkaline batteries are a good choice for flashlights used intermittently or in low-demand situations.
• Lithium Batteries: Lithium batteries offer higher capacity and a longer shelf life compared to alkaline batteries. They perform well in extreme temperatures and have a lower self-discharge rate. However, they can be more expensive. Lithium batteries are ideal for high-performance flashlights that require long runtime and reliability.
• Rechargeable Batteries (Li-ion, NiMH): Rechargeable batteries are cost-effective over time and environmentally friendly. Lithium-ion (Li-ion) batteries are known for their high capacity and long life, while nickel-metal hydride (NiMH) batteries are a popular choice for rechargeable options. Ensure that your flashlight supports the type of rechargeable battery you choose. Rechargeable batteries often come with built-in charging circuits, which can be convenient.
• CR123A Batteries: CR123A batteries are often used in high-performance flashlights due to their long battery life and high output. They are more expensive than alkaline batteries but offer excellent performance in terms of brightness and runtime.

Battery Tips:

• Check Battery Life: Review the flashlight's runtime specifications to ensure it meets your needs. Consider how long the flashlight operates on a single charge or set of batteries and whether it aligns with your usage patterns.
• Evaluate Charging Options: Some flashlights feature built-in USB charging capabilities, which can be very convenient. Evaluate the charging options available and choose a flashlight that suits your preferences.
• Spare Batteries: For critical situations or extended use, having spare batteries on hand is essential. Consider investing in additional batteries to ensure that you are never left in the dark.

4. Build Quality and Features

The build quality and features of a flashlight can greatly influence its usability, durability, and performance. Here are some factors to consider:

• Material: Flashlights are typically made from materials like aluminum, stainless steel, or plastic. Durable materials like aluminum or stainless steel offer better resistance to impact and environmental conditions, making them suitable for rugged use. Plastic flashlights may be lighter but can be less durable.
• Water Resistance: If you plan to use your flashlight in wet conditions, check the IPX rating. The IPX rating indicates the level of water resistance:
• IPX4: Splash-resistant from any direction.
• IPX7: Can be submerged in up to 1 meter of water for 30 minutes.
• IPX8: Can withstand continuous immersion in water beyond 1 meter. Ideal for underwater use.
• Impact Resistance: Look for flashlights with high impact resistance if you'll be using them in rough environments. Flashlights designed to withstand drops and impacts are better suited for outdoor adventures or professional use.
• Size and Weight: Balance the flashlight's size and weight against your needs. EDC flashlights are usually compact and lightweight, while tactical or professional models may be larger and heavier. Consider how the size and weight will affect portability and ease of use.

5. Additional Features

Many flashlights come with additional features that can enhance their functionality. Consider the following features based on your specific needs:

• Modes: Flashlights with multiple brightness modes (low, medium, high) offer versatility for different tasks. Some models also include special modes like strobe, SOS, or beacon. These modes can be useful for signaling or emergency situations.
• Focus Adjustment: Adjustable beam focus allows you to switch between a wide floodlight and a narrow spotlight. This feature is beneficial for tasks that require different lighting patterns, such as reading up close or illuminating a distant area.
• Holsters and Mounts: For tactical or professional use, accessories like holsters, mounts, or clips can add convenience. Holsters keep the flashlight easily accessible, while mounts allow for hands-free operation.
• Durability Features: Some flashlights come with additional durability features, such as anti-roll designs, ergonomic grips, or heat dissipation mechanisms. These features can enhance the overall usability and performance of the flashlight.

6. Budget Considerations

Flashlights are available in a wide range of prices, from budget-friendly models to high-end options. Your budget will influence the features and quality of the flashlight you can afford. Consider the following when setting your budget:

• Determine Your Priorities: Identify the features that are most important to you, such as brightness, durability, or battery life. Allocate your budget accordingly to prioritize these features.
• Evaluate Value for Money: Compare the features and performance of different flashlights within your budget. Look for models that offer the best value for money without compromising on essential aspects.
• Invest in Quality: While it's important to stay within your budget, investing in a high-quality flashlight can provide better performance and durability. A reliable flashlight can be a valuable tool for years to come.

7. Read Reviews and Test

Before making a purchase, read user reviews and, if possible, test the flashlight to ensure it meets your needs. User reviews provide insights into real-world performance, reliability, and potential issues. Testing the flashlight allows you to evaluate its brightness, beam pattern, and overall usability.

Conclusion

Choosing the right flashlight involves careful consideration of your needs, understanding key metrics like lumens and candela, and evaluating features such as battery type and build quality. By following this comprehensive guide, you can make an informed decision and select a flashlight that will serve you well in various

The post The Comprehensive Guide to Buying a Flashlight: What You Need to Know appeared first on HamRadio.My - Ham Radio, Fun Facts, Open Source Software, Tech Insights, Product Reviews by 9M2PJU.

22 Jul 2024 4:27pm GMT

Introduction

When managing Unix-like operating systems, understanding permission settings and security practices is crucial for maintaining system integrity and protecting data. FreeBSD and Linux, two popular Unix-like systems, offer distinct approaches to permission settings and security. This article delves into these differences, providing a comprehensive comparison to help system administrators and users navigate these systems effectively.

1. Overview of FreeBSD and Linux

FreeBSD is a Unix-like operating system derived from the Berkeley Software Distribution (BSD), renowned for its stability, performance, and advanced networking features. It is widely used in servers, network appliances, and embedded systems.

Linux, on the other hand, is a free and open-source operating system kernel created by Linus Torvalds. It is the foundation of numerous distributions (distros) like Ubuntu, Fedora, and CentOS. Linux is known for its flexibility, broad hardware support, and extensive community-driven development.

2. File System Hierarchy

Both FreeBSD and Linux follow the Unix file system hierarchy but with slight variations. Understanding these differences is key to grasping permission settings on each system.

• FreeBSD: Uses the Filesystem Hierarchy Standard (FHS) but has its nuances. The /usr directory contains user programs and data, while /var holds variable data like logs and databases. FreeBSD also utilizes /usr/local for locally installed software.
• Linux: Generally adheres to the FHS. Important directories include /bin for essential binaries, /etc for configuration files, /home for user directories, and /var for variable files.

3. Permissions and Ownership

Both systems use a similar model for file permissions but have some differences in implementation and additional features.

3.1 Basic File Permissions

• FreeBSD:
• Owner: The user who owns the file.
• Group: A group of users with shared permissions.
• Others: All other users.
• Permissions are represented as read (r), write (w), and execute (x) for each category. Commands to manage permissions:
• ls -l: Lists files with permissions.
• chmod: Changes file permissions.
• chown: Changes file ownership.
• chgrp: Changes group ownership.
• Linux:
• Similar to FreeBSD, Linux file permissions are also divided into owner, group, and others.
• Commands are the same: ls -l, chmod, chown, chgrp.

3.2 Special Permissions

• FreeBSD:
• Setuid: Allows users to execute a file with the file owner's permissions.
• Setgid: When applied to a directory, new files inherit the directory's group.
• Sticky Bit: Ensures only the file owner can delete the file.
• Linux:
• Setuid: Allows a user to execute a file with the permissions of the file owner.
• Setgid: When set on a directory, files created within inherit the directory's group.
• Sticky Bit: Similar to FreeBSD, it restricts file deletion.

4. Extended Attributes and ACLs

4.1 FreeBSD:

FreeBSD supports Extended File Attributes (EAs) and Access Control Lists (ACLs) to provide more granular permission control.

• Extended Attributes: Used to store metadata beyond standard attributes. Managed with setfattr and getfattr.
• Access Control Lists (ACLs): Allow setting permissions for multiple users and groups. Managed with setfacl and getfacl.

4.2 Linux:

Linux also supports Extended Attributes and ACLs.

• Extended Attributes: Managed with setxattr and getxattr.
• Access Control Lists (ACLs): Managed with setfacl and getfacl.

5. Security Models and Practices

5.1 FreeBSD Security Model:

FreeBSD includes several features for enhanced security:

• Jails: Provide a form of operating system-level virtualization. Each jail has its own filesystem, network configuration, and process space, which helps in isolating applications and services.
• TrustedBSD Extensions: Enhance FreeBSD's security by adding Mandatory Access Control (MAC) frameworks, which include fine-grained policies for file and process management.
• Capsicum: A lightweight, capability-based security framework that allows developers to restrict the capabilities of running processes, minimizing the impact of potential vulnerabilities.

5.2 Linux Security Model:

Linux employs a range of security modules and practices:

• SELinux (Security-Enhanced Linux): A set of kernel-level security enhancements that provide mandatory access controls. It defines policies that restrict how processes can interact with files and other processes.
• AppArmor: A security module that restricts programs' capabilities with per-program profiles. Unlike SELinux, it uses path-based policies.
• Namespaces and cgroups: Used for containerization, allowing process isolation and resource control. These are the basis for technologies like Docker and Kubernetes.

6. System Configuration and Management

6.1 FreeBSD Configuration:

FreeBSD uses configuration files located in /etc and other directories for system management. The rc.conf file is central for system startup and service configuration. The sysctl command is used for kernel parameter adjustments.

6.2 Linux Configuration:

Linux configurations are distributed across various directories like /etc for system-wide settings and /proc for kernel parameters. Systemd is the most common init system, managing services and their dependencies. The sysctl command is also used in Linux for kernel parameter adjustments.

7. User Management

7.1 FreeBSD:

FreeBSD manages users and groups through /etc/passwd, /etc/group, and /etc/master.passwd. User and group management commands include adduser, pw, and groupadd.

7.2 Linux:

Linux also uses /etc/passwd and /etc/group for user management. User and group management commands include useradd, usermod, groupadd, and passwd.

8. Network Security

8.1 FreeBSD:

FreeBSD offers robust network security features, including:

• IPFW: A firewall and packet filtering system integrated into the kernel.
• PF (Packet Filter): A powerful and flexible packet filter that provides firewall functionality and network address translation (NAT).

8.2 Linux:

Linux provides several options for network security:

• iptables: The traditional firewall utility for configuring packet filtering rules.
• nftables: The successor to iptables, offering a more streamlined and flexible approach to packet filtering and NAT.
• firewalld: A front-end for iptables and nftables, providing dynamic firewall management.

9. Backup and Recovery

9.1 FreeBSD:

FreeBSD supports several backup and recovery tools:

• dump/restore: Traditional utilities for file system backups.
• rsync: For incremental backups and synchronization.
• zfs snapshots: ZFS filesystem features allow creating snapshots for backup and recovery.

9.2 Linux:

Linux offers a range of backup and recovery tools:

• tar: A traditional tool for archiving files.
• rsync: For incremental backups and synchronization.
• LVM snapshots: Logical Volume Manager features provide snapshot capabilities.

10. Conclusion

Both FreeBSD and Linux offer robust permission settings and security features, each with its strengths and specific implementations. FreeBSD provides a comprehensive suite of security features, including jails and Capsicum, while Linux offers a variety of security modules like SELinux and AppArmor. Understanding these differences is crucial for system administrators to effectively manage and secure their systems. By leveraging the unique features of each operating system, administrators can enhance their systems' security and maintain a robust and reliable computing environment.

The post Understanding Permission Setting and Security on FreeBSD vs. Linux appeared first on HamRadio.My - Ham Radio, Fun Facts, Open Source Software, Tech Insights, Product Reviews by 9M2PJU.

22 Jul 2024 2:09pm GMT

Another week has raced by (time flies when you're having fun?). flock to fedora is coming up really fast now. It's Aug 7th to 10th in Rochester, NY. Looking forward to meeting up with everyone there and having some great discussions. I have a talk (which I still need to write up) on matrix, which should be fun and then a Infrastructure and Release Engineering hackfest which I need to work on organizing a bit more. Look for more info on discussion.

On monday I managed to get updated firmware for our aarch64 emag's. Got them all updated, reinstalled and re-added as builders just barely in time for the mass rebuild. This sort of thing takes a really tremendous amount of time. I'd like to explain for those that haven't had this sort of fun before. There's a lot of parts of this process where you need to wait for something to happen and do something in reaction to it. ie, wait for one firmware (there's 3 on these aarch64 machines) to finish updating, then reload and upload the next one. For some reason I couldn't force them to pxe boot in all cases, so that meant: login to serial console, watch the server boot, when it gets to a specific point hit esc-shift-1 to pxe boot. If you miss it, you have to start over. You might think you could do other things while this is happening, but… when you do, you always miss the window to hit the key and have to keep doing it over and over. Next fun with these was that they have 4 interfaces and for some unknown reason, they are all active on various vlans and which one gets the 'default' route is somewhat random. If it's not the actual builder network, it can't reach resources and fails the install. Some times one or more of the interfaces wouldn't come up with a cryptic error. If this was the main network, you had to reboot and try again. Once they were pxe booted the kickstart install and ansiblizing was easy. Hopefully they will work on now until we retire them.

Our resultsdb app's pods have been restarting. It's not super clear as to the cause. They hit max threads and the health check fails and then they restart, but the reason for the max threads isn't clear. Is it somehow getting blocked on database writes so requests pile up? Or is it just getting too many requests at once to handle properly. I looked at it some, but the resultdb image that we use is made by the factory2 team (which no longer exists), and it's not very easy to enable debugging in. Will look at it more next week.

Overall this week I didn't feel like I got much done. Too many things that are difficult/require a lot of time and it's hard to feel progress on them. Hopefully next week will go better!

20 Jul 2024 4:56pm GMT

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. It also contains updates for CPE (Community Platform Engineering) Team as the CPE initiatives are in most cases tied to I&R work.

We provide you both an infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in-depth details look below the infographic.

Week: July 15-19, 2024

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It's responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces, etc.).
List of planned/in-progress issues

Fedora Infra

• In progress:
  • rhel7 EOL
  • Migration of registry.fedoraproject.org to quay.io
  • add monitoring for dnf countme
  • Replace Nagios with Zabbix in Fedora Infrastructure
  • notifications do not notify
  • PDC retirement
  • Move from iptables to firewalld
  • Update compose hosts to get latest pungi release (4.6.0)
  • Deploy new sign hardware/software
  • Commits don't end up on the scm-commits list
  • Create monitoring tool for rabbitmq certificates
  • Request for new FAS group: miracle-sig
  • Private mirror check-in with mirrormanager fails
  • rhel9 adoption
  • How do I set up FAS login for discussion.stg.fedoraproject.org?
  • Private mirror check-in with mirrormanager fails
  • Still CC'ed in Chromium security bugs even though I'm not in points of contact anymore
  • EPEL minor version archive repos in MirrorManager
  • Cleaning script for communishift
  • Grant additional permissions to the fedimg AWS role
  • fedmsg -> fedora-messaging migration tracker
  • rhel7 EOL - github2fedmsg
  • rhel7 EOL - Fedimg
  • COPR cannot pull git repo from fedorapeople
  • Searching mailing list archives does not work
  • Feature / Change request: make the Fedora bugzilla more accessible
  • Need to compress logs on log01
  • AWS: support creating S3 buckets
  • AWS: Support adding elastic IPs
  • Moderating mailing list viewing message shows "This held message has been lost."
  • release-monitoring.org crawlers seem to not be running since ~June 26
  • buildhw-a64 01,02,19,20,21,22,23,24 not booting
  • STG Bugzilla doesn't send messages to STG fedora-messaging
  • Support allocation dedicated hosts for Testing Farm
• Done:
  • COPR cannot pull git repo from fedorapeople
  • Disable posts on mailman01.stg
  • Planned Outage - Server updates/reboots - 2024-07-10 21:00 UTC
  • developer sync broken with move to rhel9
  • koji builders: Update flatpak-module-tools to fix compat with zstd metadata
  • Enable markdown formatting for CoreOS CI maubot instance
  • Enable Auto-Signing for f41-rebuild Mass-Rebuild Tag
  • Update Fedora Planet wiki
  • Spam in AskFedora
  • Request for m4.10xLarge Instance to Support Fedora Apps Containerisation

CentOS Infra including CentOS CI

• In progress:
  • Decommission old dedicated hardware used for c7/c8s builds
  • HDD issue on internal storage server used for Stream
• Done:
  • Nothing as Fabian is on PTO

Release Engineering

• In progress:
  • Fedora 41 Mass Rebuild has started.
  • Packages that fail to build SRPM are not reported during the mass rebuild bugzillas
  • i686 builders need to use 32-bit inode numbers
  • When orphaning packages, keep the original owner as co-maintainer
  • Use an automated script to control checksums of compose images
  • Create an ansible playbook to do the mass-branching
  • Package retirements are broken in rawhide
  • Implement checks on package retirements
  • Update bootloader components assignee to "Bootloader Engineering Team"for Improved collaboration
  • Cleaning old stuff from koji composes directories
  • Untag containers-common-0.57.1-6.fc40
  • Renaming distribution media for Fedora Server
  • Remove PDC from package retirement process
  • Fix tokens for ftbfs_weekly_reminder. Script
  • Fedora-34-Beta .composeinfo file
  • Publish x86_64/aarch64 containers to the new AWS container repo
  • Update block_retired.py to use bodhi api
  • orphan-all-packages.py should remove bugzilla_contact entries from fedora-scm-requests as well
  • Retire EPEL 8 Next
  • unmaintained bot account: dummy-test-package-gloster gating pipeline tests broken
  • Drop modularity from EPEL8.
  • Fedora 41 Mass Rebuild Tracker
  • Some (?) retired packages not actually getting retired since ~2 days ago
  • EPEL 8 buildroot broken (no platform-python)
  • Unretire 0install
• Done:
  • Request EPEL-X build privilege for git-review repo
  • Untag selinux-policy-41.8-1.fc41
  • Stalled EPEL package: python-anyjson
  • Missing i686 package

CPE Initiatives

EPEL

Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high-quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux (SL) and Oracle Linux (OL).

Updates

• Fix deprecation warnings in toddlers
• Add EPEL 10 support to scm_request_processor toddler
• Worked with releng to isolate issue with EPEL 8 builds
• Adjusted CentOS batcave scripts to delete excluded content
• Updated tinyproxy in EPEL 8, EPEL 9, F39, F40, and Rawhide to address CVE-2023-49606

Community Design

CPE has a few members who are working as part of the Community Design Team. This team is working on anything related to design in the Fedora Community.

Updates

• Podman: Improving consistency across all pages
• CoreOS 5th anniversary designs
• Swag designs for Flock o
• last day to vote for F42 inspo on Fedora discussions

ARC Investigations

The ARC (which is a subset of the CPE team) investigates possible initiatives that CPE might take on.

Updates

• Git Forge Investigation
  • Akashdeep Dhar has provided the recap on Git Forge Investigation so far to Ryan Lerch on a 1:1 meeting call
  • Akashdeep Dhar plans to get started with investigating the self-hosted GitLab deployment on the user stories
  • Akashdeep Dhar has provided service accounts to Tomas Hrcka, Kevin Fenzi, and Ryan Lerch
  • Ryan Lerch wants to work on investigating GitLab on the user stories provided using the service account
  • Tomas Hrcka will be meeting with the Fedora Governance team
    • Share the inability to share the final comparison until Flock
    • Open up INVITE-ONLY deployments for GitLab and Forgejo during Flock
  • Michal Konecny is looking into deploying Forgejo at his end
  • Tomas Hrcka plans on opening the meetings up to the open community
    • Especially for testing the user stories with the provided deployment for GitLab and Forgejo made by us on OpenShift
  • David Kirwan and Lenka Segura joined the ARC investigation efforts with helping with the OpenShift deployments of GitLab and Forgejo
  • This limited access and INVITE-ONLY deployment would be made available to community members to help with user stories

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

The post Infra and RelEng Update - Week 29 2024 appeared first on Fedora Community Blog.

19 Jul 2024 10:00am GMT

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, the perfect solution for such tests, and also as base packages.

RPMs of PHP version 8.3.10RC1 are available

• as base packages in the remi-modular-test for Fedora 38-40 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

RPMs of PHP version 8.2.20RC1 are available

• as base packages in the remi-modular-test for Fedora 38-40 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

The packages are available for x86_64 and aarch64.

PHP version 8.1 is now in security mode only, so no more RC will be released.

Installation: follow the wizard instructions.

Announcements:

• PHP 8.3.10RC1 available for testing
• PHP 8.2.22RC1 available for testing

Parallel installation of version 8.3 as Software Collection:

yum --enablerepo=remi-test install php83

Parallel installation of version 8.2 as Software Collection:

yum --enablerepo=remi-test install php82

Update of system version 8.3:

dnf module switch-to php:remi-8.3
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.2:

dnf module switch-to php:remi-8.2
dnf --enablerepo=remi-modular-test update php\*

Notice:

• version 8.3.10RC1 is also in Fedora rawhide for QA
• version 8.4.0alpha2 is also available in the repository
• EL-9 packages are built using RHEL-9.4
• EL-8 packages are built using RHEL-8.10
• EL-7 packages are built using RHEL-7.9
• oci8 extension uses the RPM of the Oracle Instant Client version 23.4 on x86_64 or 19.23 on aarch64
• intl extension uses libicu 73.2
• RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
• versions 8.2.22 and 8.3.10 are planed for August 1st, in 2 weeks.

Software Collections (php82, php83)

Base packages (php)

19 Jul 2024 5:54am GMT