Dave Täht RIP

Post Syndicated from corbet original https://lwn.net/Articles/1016109/

[Dave Täht]

From the LibreQoS site comes the sad
news
that Dave Täht has passed away. Among many other things, he bears
a lot of credit for our networks functioning as well as they do. “We’re
incredibly grateful to have Dave as our friend, mentor, and as someone who
continuously inspired us – showing us that we could do better for each
other in the world, and leverage technology to make that happen. He will be
dearly missed
“.

Searching through LWN’s archives will turn up many references to his work
fixing WiFi, improving queue management, tackling bufferbloat, and more. Farewell,
Dave, we hope the music is good wherever you are.

(Thanks to Jon Masters for the heads-up).

A New Approach to Managing Vulnerabilities is Required – Work Smarter not Harder with Rapid7 Remediation Hub

Post Syndicated from Peter Whibley original https://blog.rapid7.com/2025/04/01/a-new-approach-to-managing-vulnerabilities-is-required-work-smarter-not-harder-with-rapid7-remediation-hub/

A New Approach to Managing Vulnerabilities is Required - Work Smarter not Harder with Rapid7 Remediation Hub

The volume of common vulnerabilities and exposures (CVEs) identified has now reached a level that even the organization tasked with managing them can no longer keep up. The National Vulnerability Database (NVD) announced in February 2024 that it would no longer provide common vulnerability scoring system (CVSS) scores for all CVEs.

This decision was down to resource constraints and an inability to keep up with the volume of newly-disclosed vulnerabilities. The NVD has now shifted its focus to processing vulnerabilities more efficiently by relying on vendor-provided and third-party scores rather than scoring each CVE independently.

The Growing Vulnerability Challenge

In 2024, there were over 40,000 Common Vulnerabilities and Exposures (CVEs) published, which is a 38% increase from 2023. All of this is before organisations begin looking at other non-CVE vulnerabilities (configuration issues, outdated systems, elevated privileges etc) that can be just as important as vulnerabilities that do have a CVE. Even the NVD is saying that a new approach to vulnerability management is required.

The Limits of Traditional Risk-Based Vulnerability Management

A key component of Risk Based Vulnerability Management (RBVM) is prioritization. Prioritizing vulnerabilities based on their calculated risk scores, then focusing on addressing or remediating the highest-risk vulnerabilities first.

However, in the high volume vulnerability landscape we face today, security teams are often faced with multiple vulnerabilities with similar high priority risk scores? What do you tackle first?

Many organizations, including Rapid7, are addressing this issue by adding more context when calculating risk score including the use of AI. But still the challenge remains, what do you prioritize first if vulnerabilities have the same risk score?

Introducing Remediation Hub: A Solution First Approach

That’s where Remediation Hub can help. Rapid7’s Remediation Hub takes a remediation-based view rather than an individual CVE based view of vulnerability management. It shows security teams the volume of vulnerabilities that will be resolved by carrying out a recommended remediation. This allows security teams to carry out bulk vulnerability removal by selecting a recommended remediation.

Recommended remediations are still prioritized based on risk, specifically a group risk score that considers:

  • The number of vulnerabilities that will be resolved.
  • The criticality of the vulnerabilities.
  • The number of assets impacted and their exploitability.

Rather than simply focusing on remediating a single CVE with the highest risk, security teams are instead guided to focus their work where it will be most effective, deliver the biggest impact on overall risk and thus drive improvement to employee productivity.

Unifying Security Operations with Exposure Command

Remediation Hub is a foundational component of the Exposure Command cybersecurity platform. Within the Exposure Command platform, Remediation Hub acts as a centralised location for all remediation efforts and is tightly integrated with the various platform components.

Via integration between Surface Command, Rapid7’s attack surface management (ASM) platform, and Remediation Hub, users can now see recommended remediations when viewing an individual asset or the asset inventory. Within the Remediation Hub itself users can drill down to obtain information and more context on the assets impacted by carrying out a specific remediation.

Security teams can see concrete vulnerability evidence or proof before assigning fixes to remediation teams and can export a prioritized list of solutions for streamlined remediation. This tight integration improves employee productivity and accelerates mean-time-to-remediate (MTTR), eliminating the need to jump between tools to obtain more context.

How the Rapid7 Remediation Hub Works

Remediation Hub ingests vulnerability data from both customer cloud and on-prem landscapes. Rather than presenting security professionals with a long list of vulnerabilities identified across their attack surface, Remediation Hub  provides users with a list of recommended remediations that are prioritized based on an algorithm-driven risk score. Security employees are thus guided to where they can have the most impact in reducing overall risk.

Working Smarter in Vulnerability Management

Due to the extent, complexity and dynamic nature of today’s IT networks, it’s clear that a new approach to managing vulnerabilities is required. The focus for cybersecurity platforms like Rapid7 Exposure Command is no longer on just identifying and prioritizing vulnerabilities but on what you do with them. We need to help security teams cut through the noise, to intelligently manage vulnerabilities and focus on where they can be most effective and productive.

Security teams carrying out remediation must start working smarter not harder.

For more information on Remediation Hub:

Empowering India’s digital future: Our computing curriculum’s impact

Post Syndicated from Ben Durbin original https://www.raspberrypi.org/blog/empowering-indias-digital-future-our-computing-curriculums-impact/

The Raspberry Pi Foundation has been working in India since 2018 to enable young people to realise their potential through the power of computing and digital technologies. 

We’ve supported Code Clubs, partnered with government organisations, and designed and delivered a complete computing curriculum for students in grades 6 to 12 and at the undergraduate level. Our curriculum is tailored to the Indian context, and we provide extensive support to help teachers deliver it effectively.

Three female students at the Coding Academy in Telangana.

In another recent blog, we shared in detail how we’ve created an impactful curriculum for India. We’re now excited to share our new report evaluating how our curriculum is being taught in Telangana and Odisha. This report demonstrates the impact we’ve had so far, highlighting our successes and the key lessons we have learnt.

Key findings from the evaluation

Our evaluations of how the curriculum is being taught show that teachers are well-equipped to deliver the curriculum and provide high-quality and accessible learning experiences that develop students’ computing knowledge and skills.

A group of students in a classroom.

In Telangana, we partnered with the Telangana Social Welfare Residential Educational Institutions Society (TGSWREIS) to introduce our curriculum at the Coding Academy School and Coding Academy College. Our report found that all school and college teachers we trained agreed they felt confident teaching students using the resources provided. Students were very positive about the classes, and their assessment scores demonstrated strong learning outcomes: 77% of school students and 70% of college students achieved at least 60% of available marks.

In Odisha, we worked with Learning Links Foundation and Quest Alliance, in partnership with Panchasakha Sikhya Setu (PSS) Abhiyan, to deliver the IT and Coding Curriculum (Kaushali) to students in grades 9 and 10. Our findings were also very positive:

  • 87% of teacher respondents agreed that the curriculum resources were high quality and useful for their teaching
  • 91% felt more confident about teaching IT and coding due to the curriculum resources
  • 93% of teachers agreed that the training helped them understand the curriculum’s structure, content, and objectives
  • 89% felt confident in teaching the curriculum after the training
  • Teachers also reported a positive impact on their students, with almost all agreeing that it improved students’ coding skills, digital literacy, and understanding of responsible digital citizenship

The report also highlights how students better understood how computing and coding are used in the world and developed an increased interest in pursuing careers in these fields.

Key factors for effective implementation

Our evaluations show the importance of several factors when launching a computing curriculum:

  • Aligning content with students’ experience and interests: Content should be tailored to students’ existing knowledge, culturally relevant, and follow industry standards to prepare them for employment
  • Providing extensive support to teachers: This includes careful selection and training of master teachers, comprehensive training for teachers that considers their knowledge and experience, and ongoing support through webinars, calls, and classroom observations
  • Ensuring sufficient quantity and quality of infrastructure: Adequate equipment and internet access are crucial for effective teaching and learning

We are committed to always improving our approach to ensure that all young people in India have the opportunity to learn about computing.

Join us in shaping the future

You can read our new report here. If you are interested in partnering with us or want to learn more about our mission, please contact [email protected].

The post Empowering India’s digital future: Our computing curriculum’s impact appeared first on Raspberry Pi Foundation.

[$] Updates on storage standards

Post Syndicated from jake original https://lwn.net/Articles/1015724/

As he has in some previous editions of the Linux Storage, Filesystem,
Memory-Management, and BPF Summit (LSFMM+BPF), Fred Knight gave an update
on the status of various storage standards this year. In it, he looked at
changes to the NVM Express (NVMe)
standards in some detail. He also updated attendees on the fairly small
changes that have come to the SCSI (T10)
and ATA (T13) standards over the last few
years.

“You get Instant Purge, and you get Instant Purge!” — all purge methods now available to all customers

Post Syndicated from Alex Krivit original https://blog.cloudflare.com/instant-purge-for-all/

There’s a tradition at Cloudflare of launching real products on April 1, instead of the usual joke product announcements circulating online today. In previous years, we’ve introduced impactful products like 1.1.1.1 and 1.1.1.1 for Families. Today, we’re excited to continue this tradition by making every purge method available to all customers, regardless of plan type.

During Birthday Week 2024, we announced our intention to bring the full suite of purge methods — including purge by URL, purge by hostname, purge by tag, purge by prefix, and purge everything — to all Cloudflare plans. Historically, methods other than “purge by URL” and “purge everything” were exclusive to Enterprise customers. However, we’ve been openly rebuilding our purge pipeline over the past few years (hopefully you’ve read some of our blog series), and we’re thrilled to share the results more broadly. We’ve spent recent months ensuring the new Instant Purge pipeline performs consistently under 150 ms, even during increased load scenarios, making it ready for every customer.  

But that’s not all — we’re also significantly raising the default purge rate limits for Enterprise customers, allowing even greater purge throughput thanks to the efficiency of our newly developed Instant Purge system.

Building a better purge: a two-year journey

Stepping back, today’s announcement represents roughly two years of focused engineering. Near the end of 2022, our team went heads down rebuilding Cloudflare’s purge pipeline with a clear yet challenging goal: dramatically increase our throughput while maintaining near-instant invalidation across our global network.

Cloudflare operates data centers in over 335 cities worldwide. Popular cached assets can reside across all of our data centers, meaning each purge request must quickly propagate to every location caching that content. Upon receiving a purge command, each data center must efficiently locate and invalidate cached content, preventing stale responses from being served. The amount of content that must be invalidated can vary drastically, from a single file, to all cached assets associated with a particular hostname. After the content has been purged, any subsequent requests will trigger retrieval of a fresh copy from the origin server, which will be stored in Cloudflare’s cache during the response. 

Ensuring consistent, rapid propagation of purge requests across a vast network introduces substantial technical challenges, especially when accounting for occasional data center outages, maintenance, or network interruptions. Maintaining consistency under these conditions requires robust distributed systems engineering.

How did we scale purge?

We’ve previously discussed how our new Instant Purge system was architected to achieve sub-150 ms purge times. It’s worth noting that the performance improvements were only part of what our new architecture achieved, as it also helped us solve significant scaling challenges around storage and throughput that allowed us to bring Instant Purge to all users. 

Initially, our purge system scaled well, but with rapid customer growth, the storage consumption from millions of daily purge keys that needed to be stored reduced available caching space. Early attempts to manage this storage and throughput demand involved queues and batching for smoothing traffic spikes, but this introduced latency and underscored the tight coupling between increased usage and rising storage costs.

We needed to revisit our thinking on how to better store purge keys and when to remove purged content so we could reclaim space. Historically, when a customer would purge by tag, prefix or hostname, Cloudflare would mark the content as expired and allow it to be evicted later. This is known as lazy-purge because nothing is actively removed from disk. Lazy-purge is fast, but not necessarily efficient, because it consumes storage for expired but not-yet-evicted content. After examining global or data center-level indexing for purge keys, we decided that wasn’t viable due to increases in system complexity and the latency those indices could bring due to our network size. So instead, we opted for per-machine indexing, integrating indices directly alongside our cache proxies. This minimized network complexity, simplified reliability, and provided predictable scaling.

After careful analysis and benchmarking, we selected RocksDB, an embedded key-value store that we could optimize for our needs, which formed the basis of CacheDB, our Rust-based service running alongside each cache proxy. CacheDB manages indexing and immediate purge execution (active purge), significantly reducing storage needs and freeing space for caching.


Local queues within CacheDB buffer purge operations to ensure consistent throughput without latency spikes, while the cache proxies consult CacheDB to guarantee rapid, active purges. Our updated distribution pipeline broadcasts purges directly to CacheDB instances across machines, dramatically improving throughput and purge speed.

Using CacheDB, we’ve reduced storage requirements 10x by eliminating lazy purge storage accumulation, instantly freeing valuable disk space. The freed storage enhances cache retention, boosting cache HIT ratios and minimizing origin egress. These savings in storage and increased throughput allowed us to scale to the point where we can offer Instant Purge to more customers.

For more information on how we designed the new Instant Purge system, please see the previous installment of our Purge series blog posts. 

Striking the right balance: what to purge and when

Moving on to practical considerations of using these new purge methods, it’s important to use the right method for what you want to invalidate. Purging too aggressively can overwhelm origin servers with unnecessary requests, driving up egress costs and potentially causing downtime. Conversely, insufficient purging leaves visitors with outdated content. Balancing precision and speed is vital.

Cloudflare supports multiple targeted purge methods to help customers achieve this balance.

Starting today, all of these methods are available to every Cloudflare customer.    

How to purge 

Users can select their purge method directly in the Cloudflare dashboard, located under the Cache tab in the configurations section, or via the Cloudflare API. Each purge request should clearly specify the targeted URLs, hostnames, prefixes, or cache tags relevant to the selected purge type (known as purge keys). For instance, a prefix purge request might specify a directory such as example.com/foo/bar. To maximize efficiency and throughput, batching multiple purge keys in a single request is recommended over sending individual purge requests each with a single key.

How much can you purge?

The new rate limits for Cloudflare’s purge by tag, prefix, hostname, and purge everything are different for each plan type. We use a token bucket rate limit system, so each account has a token bucket with a maximum size based on plan type. When we receive a purge request we first add tokens to the account’s bucket based on the time passed since the account’s last purge request divided by the refill rate for its plan type (which can be a fraction of a token). Then we check if there’s at least one whole token in the bucket, and if so we remove it and process the purge request. If not, the purge request will be rate limited. An easy way to think about this rate limit is that the refill rate represents the consistent rate of requests a user can send in a given period while the bucket size represents the maximum burst of requests available.

For example, a free user starts with a bucket size of 25 requests and a refill rate of 5 requests per minute (one request per 12 seconds). If the user were to send 26 requests all at once, the first 25 would be processed, but the last request would be rate limited. They would need to wait 12 seconds and retry their last request for it to succeed. 

The current limits are applied per account: 

Plan

Bucket size

Request refill rate

Max keys per request

Total keys

Free

25 requests

5 per minute

100

500 per minute

Pro

25 requests

5 per second

100

500 per second

Biz

50 requests

10 per second

100

1,000 per second

Enterprise

500 requests

50 per second

100

5,000 per second

More detailed documentation on all purge rate limits can be found in our documentation.

What’s next?

We’ve spent a lot of time optimizing our purge platform. But we’re not done yet. Looking forward, we will continue to enhance the performance of Cloudflare’s single-file purge. The current P50 performance is around 250 ms, and we suspect that we can optimize it further to bring it under 200 ms. We will also build out our ability to allow for greater purge throughput for all of our systems, and will continue to find ways to implement filtering techniques to ensure we can continue to scale effectively and allow customers to purge whatever and whenever they choose. 

We invite you to try out our new purge system today and deliver an instant, seamless experience to your visitors.

[$] Memory persistence over kexec

Post Syndicated from corbet original https://lwn.net/Articles/1015997/

The kernel’s kexec
mechanism
allows one kernel to directly boot a new one; it can be
thought of as a sort of kernel equivalent to the execve()
system call. Kexec has a number of uses, including booting a special kernel
to perform dumps after a crash. Normally, one does not expect user-space
processes to survive booting into a new kernel, but that has not stopped
developers from trying to implement that ability. Mike Rapoport ran a
memory-management-track session at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit to discuss one piece of that problem:
enabling the contents of memory to persist across a kexec handover so that
the new kernel can pick up where the old one left off.

Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/1016076/

Security updates have been issued by AlmaLinux (freetype, grub2, kernel, kernel-rt, and python-jinja2), Debian (freetype, linux-6.1, suricata, tzdata, and varnish), Fedora (mingw-libxslt and qgis), Mageia (elfutils, mercurial, and zvbi), Oracle (grafana, kernel, libxslt, nginx:1.22, and postgresql:12), Red Hat (opentelemetry-collector), SUSE (corosync, opera, and restic), and Ubuntu (aom, libtar, mariadb, ovn, php7.4, php8.1, php8.3, rabbitmq-server, and webkit2gtk).

What’s New in Rapid7 Products & Services: Q1 2025 in Review

Post Syndicated from Margaret Wei original https://blog.rapid7.com/2025/04/01/whats-new-in-rapid7-products-services-q1-2025-in-review/

What’s New in Rapid7 Products & Services: Q1 2025 in Review

At Rapid7, we started off the year focused on delivering new features and advancements across our products and services to bring you the context needed to prioritize exposures, visualize your attack surface, and accelerate incident response. Read on for Q1 2025 release highlights across the Command Platform, from Exposure Command to Managed Threat Complete.

Eliminate blind spots with Exposure Management

Discover and protect sensitive data across hybrid environments

Keeping sensitive data secure across hybrid and multi-cloud environments isn’t easy—especially without clear visibility. Data gets misplaced, duplicated, or left exposed, making risk assessment and compliance difficult. Sensitive Data Discovery, our latest feature delivering clarity and control to your security data, can help.

Available as part of  Exposure Command and InsightCloudSec, Sensitive Data Discovery gives security teams real-time visibility into sensitive data, such as PII, financial data or customer records, across multi-cloud environments, helping identify exposures, prioritize risks, and take action faster.

With automated scanning and classification, you can pinpoint who has access to sensitive data, continuously monitor for exposures, and strengthen compliance while streamlining incident response. Learn more Sensitive Data Discovery  here.

What’s New in Rapid7 Products & Services: Q1 2025 in Review
Sensitive Data Discovery in InsightCloudSec

Intelligent vulnerability prioritization with AI-driven CVSS Scoring

In February 2024, the National Vulnerability Database (NVD) stopped providing CVSS scores for all CVEs, creating a gap in risk assessment as vulnerabilities go unscored. To bridge this gap, we’ve introduced AI-Generated Risk Scoring in Exposure Command, which uses machine learning to supplement missing CVSS scores and ensure an immediate, accurate risk rating for all CVEs without manual analysis.

This AI/ML scoring ensures all vulnerabilities are properly assessed, helping you prioritize remediation efforts efficiently and strengthen your overall security posture with the right context and insights. Discover more about AI-driven CVSS Scoring here.

What’s New in Rapid7 Products & Services: Q1 2025 in Review
CVSS Risk Scoring in InsightVM

Prioritize risk and accelerate remediation of critical exposures

To effectively prioritize remediation efforts and reduce cyber risk, you need clear contextual information about your assets and vulnerabilities. Without this, you risk misclassifying the severity of vulnerabilities and wasting effort on low-priority issues while high-risk threats remain unaddressed.

Our newly expanded Surface Command and Remediation Hub integration embeds this necessary context about assets and vulnerabilities directly within the asset inventory and detail pages of Surface Command, providing:

  • Faster mean-time-to-remediate (MTTR) by bringing prioritized remediation guidance directly to the pages your team is already working within in Surface Command.
  • Deeper asset context at the time of remediation, including insights from third-party security and ITOps tooling.
  • Improved collaboration by providing security teams and stakeholders with enriched context for quicker decision-making.

Learn more about how this integration can empower your team to act with confidence, ensuring that remediation efforts are focused on the vulnerabilities that matter most here.

MDR: A clear line of sight

New detection and response dashboard

Teams need a holistic view of threats, SOC activity, and response performance to have confidence in their program and communicate efficacy to leadership and stakeholders. Available for Managed Detection and Response customers, our new customizable Detection & Response Dashboard provides an executive-ready snapshot of your MDR program, offering real-time, easy-to-communicate insights into:

  • Threat prioritization & alert trends: Analyze the volume of alerts by severity and identify the most common alert types to understand the highest-risk threats.
  • Incident response efficiency: Threat pipeline visualization tracks how alerts progress to investigations and incidents, while mean time to begin investigating highlights response speed.
  • Investigation & resolution metrics: Insights into closed alerts and investigations by priority and disposition help teams assess the effectiveness of their threat response and remediation efforts​.
What’s New in Rapid7 Products & Services: Q1 2025 in Review
Detection and Response Dashboard in Rapid7 MDR

Learn more about the dashboard in our blog.

Transparency in AI-driven security: AI Alert Triage decisioning

Artificial intelligence (AI) has transformed security operations, enabling faster detection and response. However, black-box AI decision-making can lead to uncertainty—why was an alert escalated or dismissed?

With Rapid7’s AI Alert Triage Transparency, MDR customers gain full visibility into the reasoning behind AI-driven security actions​, such as what factors influenced alert prioritization. You’ll also benefit from Rapid7’s AI triage’s 99.89% accuracy, reducing noise and giving you more time to focus on investigating real threats. Learn more about what this means for your organization here.

What’s New in Rapid7 Products & Services: Q1 2025 in Review
AI-Powered Auto Triage in Rapid7 MDR

The latest intelligence from Rapid7 Labs

Emergent threat response: Real-time guidance for critical threats

Rapid7’s Emergent Threat Response (ETR) program from Rapid7 Labs delivers fast, expert analysis and first-rate security content for the highest-priority security threats to help both Rapid7 customers and the greater security community understand their exposure and act quickly to defend their networks against rising threats.

In Q1 2025, Rapid7’s ETR team provided expert analysis, InsightVM content, and mitigation guidance for a variety of notable vulnerabilities, including several that came under active attack. Q1 CVEs of note include:

Follow along here to see the latest emergent threat guidance from our team.

Technical assessments of CVEs in AttackerKB

This past quarter Rapid7 researchers also published additional vulnerability assessments in AttackerKB (Rapid7’s community platform for vulnerability research and threat data) to help customers and the community understand and prioritize notable CVEs:

Coordinated vulnerability disclosure

In February 2025, Rapid7 researchers discovered a novel vulnerability in PostgreSQL (now assigned CVE-2025-1094) while researching BeyondTrust CVE-2024-12356, which was exploited as a zero-day flaw in a high-profile attack on the U.S. Treasury Department.

In every scenario Rapid7 researchers tested, a successful exploit for BeyondTrust CVE-2024-12356 had to include exploitation of PostgreSQL CVE-2025-1094 in order to achieve remote code execution. See Rapid7’s full analysis of CVE-2024-12356 here and our disclosure of PostgreSQL CVE-2025-1094 here.

Stay tuned for more!

As always, we’re continuing to work on exciting product enhancements and releases throughout the year. Keep an eye on our blog and release notes as we continue to highlight the latest in product and service investments at Rapid7.

Cell Phone OPSEC for Border Crossings

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html

I have heard stories of more aggressive interrogation of electronic devices at US border crossings. I know a lot about securing computers, but very little about securing phones.

Are there easy ways to delete data—files, photos, etc.—on phones so it can’t be recovered? Does resetting a phone to factory defaults erase data, or is it still recoverable? That is, does the reset erase the old encryption key, or just sever the password that access that key? When the phone is rebooted, are deleted files still available?

We need answers for both iPhones and Android phones. And it’s not just the US; the world is going to become a more dangerous place to oppose state power.

Customizing C# and C++ with Amazon Q Developer

Post Syndicated from Brian Beach original https://aws.amazon.com/blogs/devops/customizing-c-and-c-with-amazon-q-developer/

Amazon Q Developer recently added support for customizing C# and C++ suggestions based on your company’s codebase. This blog post explores how developers can tailor the AI assistant to provide accurate inline suggestions and contextual code understanding for their C# and C++ projects. You will learn how to leverage customizations to boost productivity, streamline development workflows, and unlock the full potential of Amazon Q Developer across your codebase.

Overview

Like many developers, I learned to code in C. Thirty years later, C# and C++ are both still among the top 10 most used programming languages. However, much of that code is proprietary and stored in private repositories, while Python, JavaScript, and Java dominate public repositories. Therefore, it is critical that I can customize my AI assistant with my private, proprietary code examples. Amazon Q Developer expanded its customization capabilities to include support for C# and C++, in addition to Python, Java, JavaScript, and TypeScript that it already supports.

If you caught my session at re:Invent 2024, Best practices for customizing Amazon Q Developer, you might remember me showcasing how to customize Amazon Q Developer using a Python-based MovieRepository example. With positive feedback from the Python developers, I want to bring that same level of customization to my C# and C++ developers. So, without further delay, let’s dive in and see how you can get the most out of Amazon Q Developer in your C# and C++ projects.

Inline suggestions

Let’s start by looking at how Amazon Q Developer can provide inline suggestions. I’ll use C# for this example. Take a look at Insert method of the MovieRepository class. The MovieRepository class supports basic create, read, update, and delete (CRUD) operations. Notice that the Insert method expects four fields for each movie: title, year, plot, and rating.

/// <summary>
/// Adds a movie to the table.
/// </summary>
/// <param name="title">The title of the movie.</param>
/// <param name="year">The release year of the movie.</param>
/// <param name="plot">The plot summary of the movie.</param>
/// <param name="rating">The quality rating of the movie.</param>
public async Task Insert(string title, int year, string plot, decimal rating)
{ ... }

When I use the default, non-customized, version of Amazon Q Developer, it does its best to help me out. However, you might notice a few errors in the suggestion on line 17 of the screenshot below. First, Amazon Q Developer has suggested a reference to a method named AddMovie, but the actual method in the MovieRepository class is named Insert. Second, Amazon Q Developer guessed three of the four parameters correctly – title, year, and rating, but suggested a director rather than plot. Third, the order of the parameters is not correct.

C# code showing a MovieDatabase namespace containing a Program class with a Main method. The code creates a MovieRepository instance and adds the movie "Titanic" to the database with director James Cameron, year 1997, and rating 7.8 using an async method.

Of course, I cannot fault Amazon Q Developer for these mistakes. It has never seen the MovieRepository, which is stored in a private repository. Now, let’s switch over to my customized version of Amazon Q Developer. Note that I have created a customization following the instructions in the Amazon Q Developer User Guide and the best practices discussed in my re:Invent talk. I simply activate the customization in my IDE.

A dialog box titled "Select a Customization" showing two options: "Amazon Q foundation (Default)" with the description "Receive suggestions from Amazon Q base model" and "amazon-q-developer-customization-demo" marked as "Connected" with "No description provided". The dialog has a back arrow, title, help icon, and close button in the header.

With the customization selected, Amazon Q Developer now understands the exact structure of my MovieRepository class. Look at the suggestion on line 17 of the following image. With the customization enabled, Amazon Q Developer has correctly suggested the method name, parameter names, and parameter order. In addition, it understands that MovieRepository is using Amazon DynamoDB behind the scenes. Finally, notice that this suggestion spans multiple lines, while the prior example was all on one line. Amazon Q Developer is formatting the code to match my team’s preferred style, with each parameter on a separate line, based on the examples it saw in my customization.

C# code showing a MovieDatabase namespace containing a Program class with a Main method. The code creates a MovieRepository instance and uses InsertAsync to add the movie "Titanic" to DynamoDB with details including the title, year 1997, a partial plot description, and rating of 7.8.

This is the power of customization: Amazon Q Developer is tailoring its suggestions to fit my codebase and preferences. The customization benefits don’t stop at inline suggestions. Let’s take a look at how Amazon Q Developer can assist me in chat, this time using a C++ example.

Chatting about code

In addition to inline suggestions, my customization is also available in the chat. Personally, I use a combination of inline suggestions and chat. I prefer the inline suggestions when I know the codebase and want to work faster. I prefer chat when I do not know the codebase well and I want Amazon Q Developer to provide additional context.

In the following example, I ask Amazon Q Developer – “How to I add movies to the C++ MovieRepository.” I should note that the customization is still enabled and that the single customization supports C# and C++ in addition to Python, Java, JavaScript, and TypeScript. I do not need to enable a different customization for each language.

Once again, Amazon Q Developer provides accurate information about the MovieRepository structure. In addition, the response includes additional instructions and multiple examples (though I only included one in the screenshot). Also, you may have noticed that Amazon Q Developer is a sci-fi fan. I’m not surprised.

A code snippet in C++ showing how to add a movie to the MovieRepository using the Insert method. The example adds "The Matrix" with its release year (1999), a brief plot description, and rating (8.7). The code includes error handling that outputs success or failure messages. The snippet appears to be part of a larger response explaining different ways to add movies to a repository.

But wait, there’s more! Amazon Q Developer has also read my README files. Therefore, it can answer questions about usage, installation, troubleshooting, and more. In this final example, I will ask Amazon Q Developer for help troubleshooting. Amazon Q Developer makes multiple suggestions (though I only included one in the screenshot) about potential issues and how to fix them.

Code example showing two methods for configuring AWS credentials in a C++ MovieRepository. The first option uses environment variables with export commands for AWS access keys. The second option shows the format for storing credentials in a ~/.aws/credentials file. This appears to be part of a troubleshooting guide addressing common AWS authentication issues.

The impact of customization on the inline suggestions and chat combine to keep me focused and in a state of flow.

Conclusion

I’m thrilled to have the ability to customize Amazon Q Developer for my C# and C++ projects. Whether I’m looking for inline suggestions or need help understanding my codebase through the chat feature, this tool has become an invaluable part of my development workflow. If you haven’t already, I’d highly encourage you to check out the Amazon Q Developer documentation and start leveraging the power of customization for your own projects.

Installing and Configuring Zabbix Server and Agent on Windows

Post Syndicated from Zabbix LatAm original https://blog.zabbix.com/installing-and-configuring-zabbix-server-and-agent-on-windows/29945/

Monitoring a Windows server helps verify and keep track of reboots, disk space, memory, CPU, communication loss, and high bandwidth consumption within the server – in fact, anything unusual that may require attention. In this post, we’ll see how to install and configure the Zabbix server and Zabbix agent on Windows, highlighting the key points that will keep your system running smoothly.

Check Zabbix server version

First, check which version of Zabbix server you’re using. This can be verified from the frontend in Reports > System information. In this example, we use version 7.0.9.

Before you begin, head over to your Windows server and verify the name and type of architecture.

This is critical to selecting the right agent during deployment.

Download the Zabbix agent

From the official Zabbix website, download the corresponding agent, taking into account the operating system (in this case, Windows), the hardware architecture (64 bits), the version of Zabbix server (ensuring compatibility with the version used), encryption (using OpenSSL as an encryption method), and the installation format (selecting the MSI file).

Select the current version of the release and download.

Install the Zabbix agent

Start installing the Zabbix Agent on the Windows server.

Accept the terms and conditions.

Check the components to be installed. You’ll need at least 8.70 MB of disk space.
The default installation path is C:\Program Files\Zabbix Agent\.

By default, the installer detects the name of the server. Enter the IP of your Zabbix Server. You can also use pre-shared keys.

Start the installation and wait for it to finish.

Configure host in Zabbix Server

To set up a host on Zabbix Server, go to the Zabbix frontend and go to Data collection > Hosts.

Then, click Create host (located in the top right) and configure the following details:

• The hostname (DESKTOP-D75R1IG)
• An identifying display name (such as ‘Windows Server’)
• The template (select ‘Windows by Zabbix Agent’)
• The group (assigns the server to an appropriate group)
• The interface (choose the agent monitoring option and enter the IP of the server)

Monitoring and visualization

Once the host is configured, you will start receiving data from the server in Zabbix, including:

• Overall performance: CPU, memory, and disk status.

• Windows services and detailed host information.

• Bandwidth consumption

Conclusion

Zabbix provides an ideal template for a productive environments on Windows, making it a key tool for global monitoring of your servers.

In addition, you can extend and adapt the monitoring according to your needs, such as monitoring logs, ports, or specific events, while also checking for login failures or other critical issues in your systems.

 

The post Installing and Configuring Zabbix Server and Agent on Windows appeared first on Zabbix Blog.

Има ли криза в българското кино?

Post Syndicated from original https://www.toest.bg/ima-li-kriza-v-bulgarskoto-kino/

Има ли криза в българското кино?

В „Има ли филм през 2024 г. в българското кино?“ обобщих качествата и проблемите на българските филми в разпространение от ноември 2023 г. до края на 2024 г. Сега ще се фокусирам върху подбора на проектите, финансирани от Националният филмов център (НФЦ).

Не искам да вярвам, че сценариите на излезлите филми са най-добрите, които българските творци са написали. Не мога да приема и че комисиите в НФЦ са подкрепили най-добрите проекти. Ако наистина е така, то проблемът трябва да се сведе до ниво образование. Но и в двата случая е нужна реформа. 

Как е сега? 

Няколко комисии и групи работят от години по промени в Закона за филмовата индустрия (ЗФИ). Какъв е резултатът? Работна група, предлагаща промени в Правилника за прилагане на ЗФИ (ППЗФИ) през 2023 г., е издала 37 заповеди и протоколи. Самата тя е съставена от действащи (кандидатстващи по проекти в НФЦ) кинаджии, излъчени от браншовите асоциации. Същите излъчват и участници в подбора на членове на комисиите. Голяма част от тях получават и субсидии за филми. С други думи, участниците в процеса създават предложения за „реформа“ на системата. Това е предпоставка за конфликт на интереси.

В НФЦ има 8 комисии, две от които с по два състава. Те работят здраво, ако се съди по десетките документи, хаотично публикувани онлайн от НФЦ. Сайтът на Центъра заслужава отделен обзор, защото в този си вид по-скоро крие, отколкото предоставя информация.

НФЦ като разпределител на бюджетни средства

НФЦ не успява да е коректив и да подбира добре структурирани сценарии със значими и ясни теми. На такава основа добрата режисура и актьорска игра трудно могат да блеснат. Операторската работа някак се извисява самостоятелно над останалото. Това заключение е тревожно въпреки обявените чудесни резултати. Отчетът на НФЦ за 2023 г. сочи, че при планирани 35 игрални, документални и анимационни филма са произведени 31. „Високата“ цел, която НФЦ си поставя, е общо 100 000 зрители. Това е средно едва по 2850 зрители на филм! Отчетени са четири пъти повече зрители. Звучи като изпълнен план, а всъщност е провал. Дори само слабият творчески, но силен с темата и познаването на аудиторията си „Русалки“ привлича 69 000 зрители, а бюджетът му е на половината на ниския клас бюджети на НФЦ.

Има случаи, в които зрителите на филм с бюджет от около 900 000 лв. не надвишават 5000. НФЦ е дотирал тези филми, гледани от 185 000 зрители, с 6 450 000 лв. Частно финансираните филми струват малко повече, ако включим и 4-милионния бюджет на „Гунди – легенда за любовта“, но привличат десетократно по-голяма аудитория. Това е скандално! 

Има ли в съсловието енергия за реформа?

Кинообщността в България е малка. Повечето работещи в нея са професионалисти, които снимат филм след филм. Благодарение на участието си в чужди продукции, изгубените в Прехода кинаджии започнаха да работят на високо ниво. За тях е важно да имат ангажименти и не успяват да се превърнат в критична маса, радееща за реформа. Рядко първи асистент, осветител или гримьор отказва филм по творчески причини. Много режисьори, след като не успеят да реализират проект, престават да се борят или се присламчват към някоя от компаниите или лобитата, работещи от дотация на дотация. Други снимат реклами и сериали, но проектите им са често неуспешни. Има дистрибутори, които се опитват да направят филми със свой, комерсиален почерк. За тях най-доброто, което се случва, е евтина откупка в някоя от платформите за VOD, като НВО (MAX), Netflix, Neterra, „Гледам“. Професионалните сценаристи са малко и се издържат от сериали.

Закон за филмовата индустрия 

Основният проблем се крие в закона, който бламира опитите на всяко ръководство на НФЦ да бъде съзидателно. В ЗФИ е записано, че комисията, оценяваща проектите, се състои от членове на творчески гилдии, които НФЦ регламентира. Журито се избира с жребий и вотът на членовете му е явен. Достатъчно е един да гласува против, за да потопи даден проект на дъното на класацията. Комисиите не участват в производството на филмите. Дори на теория никой не е отговорен за нищо. Критериите, по които се гласува, на хартия са ясни, но са изключително общи. 

Нали основата все пак е сценарият? Колко от участниците в комисии разбират каква трябва да е неговата структура? Това е специфична материя, която се усвоява дълго. Основните проблеми се коренят тъкмо там, а членовете на комисията оценяват нещо, което явно не разбират. 

Знам, че може да получа критики за тези думи. Но резултатите говорят сами.

Основният носител на идеята и темата е сценаристът. Визионерът, който застава зад дадена тема в точния исторически момент, е продуцентът. Преводачите на темата на киноезик са режисьорът, операторът и актьорският състав. Творците са такива, каквито социалната среда ги е създала. Такъв е капиталът на обществото в тази сфера, в тази епоха. Това, което трябва да се оценява, е дали темата е добре защитена, дали сценарият има професионално изградена структура и дали е добра основа, върху която да твори режисьорът. 

Другото, което членовете на комисията следва да решат, е дали темата не противоречи на основни ценности, зад които обществото ни застава. И тук не е нужно кинаджии да описват тази ценностна система. Списъкът от желаещи да оценяват включва 274 кандидати. Силно се съмнявам, че толкова хора в България могат да направят професионален анализ на киносценарий. 

Идеи за реформа на НФЦ

В световната киноиндустрия съществуват т.нар. film bonding компании – това са гаранти пред финансиращите фирми или институции, че бюджетът на един проект ще бъде инвестиран разумно. При провал проектът става тяхна собственост и те могат да го завършат, както сметнат за добре. Добре би било НФЦ да възприеме елементи от тази практика.

Добре е финансирането на филми да става след няколко нива на оценяване. Понякога добрите сценарии може да са придружени от недотам добри проекти за осъществяване, и обратното. Нужен е фонд под егидата на НФЦ със сценарии и лаборатория за такива с добри идеи, но имащи нужда от още работа. Текстовете, които постъпват в конкурсите на НФЦ, са съкровищница. Повечето от тях са написани неумело, липсват им структура, ясна тема и конфликт. Но в тях се съдържа това, която вълнува българските творци. Дори несъвършен, всеки от тях е документ на времето си. 

След няколко отказа обаче сценариите умират.

Така си отиват идеите и темите, заложени в тях. Ако НФЦ направи банка за най-добрите отхвърлени идеи, комисиите ще могат да се връщат към тях. В такъв случай проектите могат да се класират от професионални сценарни консултанти още преди на сцената да се появи продуцентът. Структурата им е ясна материя, тя се журира по ясни правила, като се започне с професионално форматиране. Така ще отпадне значителен брой некачествени проекти, а същият филтър следва да се приложи и към оценяващите.

Продуцентите ще могат да избират от вече оценени и професионално отсети проекти. Сценариите, запазени във фонд, биха могли да се предлагат на други режисьори и продуценти. Време е българският продуцент да не се възприема само като директор, разпределящ парите. Той е носител на темата, която трябва да резонира в публиката, и следва да носи отговорност не само за успехите, а и за провалите си и би следвало да има възможност за банков заем за филм с гарант НФЦ.

Необходимо е НФЦ да участва в процеса на създаване на всеки филм. Разбирам, че проектите за една конкурсна сесия са много – само за 2024 г. са регистрирани 52-ма нови продуценти. Но идеята, че количеството води до качество, е грешна. Напротив – качеството води до повече качество. Затова е необходимо да има отговорност за всеки сценарий, който е допуснат за по-нататъшно оценяване на творческия подход на режисьора, оператора, монтажиста и актьорския екип. Много важен критерий е как продуцентът ще произведе добрия сценарий.

Финансиране

Системата за финансиране на българското кино се нуждае от децентрализация. Може да се създадат различни фондове, които да допринасят за съставянето на бюджет за филм. Добре е да има такива не само на национално, но и на местно ниво. И сега общините имат някакви нищожни средства за кино. Една кинопродукция би донесла приходи в областен град и разбирането за това следва да е заложено в по-обща визия за филмово финансиране. 

Киното се конкурира с останалите форми на забавление – концерти, театрални постановки, дори кръчми, ресторанти и дискотеки. Хората имат нужда от емоция и са склонни да плащат за това. Колкото повече пари за кино, толкова по-добре. Но те трябва да се увеличат след реформа на системата и ЗФИ, която да е предпоставка киното да стане конвертируем продукт. Крайно време е финансирането на предподготовка на проект да отпадне по същия начин, както ненадейно се появи. С подробното представяне на бюджетите биха се избегнали спекулациите.

Забелязва се тенденция на главоломно увеличаване на финансирането на българско миноритарно участие в микробюджетни чужди копродукции. За последните две години са сключени 34 договора за общо 5 435 050 лв. Би било добре НФЦ да се стреми към по-високобюджетни копродукции и мажоритарно участие, вместо да залага на количество. Мястото и на тези филми е в българските салони. В момента те са невидими.

Конфликти на интереси 

НФЦ трябва да премахне участието на действащи кинотворци в оценяването на проекти на колеги, което е основен проблем в закона в сегашния му вид. Това е прикрит конфликт на интереси, един омагьосан кръг, който мнозина „работещи“ кинаджии бранят с цената на всичко. Тази система убива вярата на младите, че с талант и труд могат да осъществят идеите си. След няколко години гонене на химери и борба с вятърни мелници дебютантите започват да се присламчват към някое лоби, приспособило се към системата. Разговорите между участващи и журиращи са непредотвратими, което създава „чудесна“ корупционна среда. 

През последните години група продуценти и режисьори, които се въртят в световната фестивална мрежа, успяха да въведат служебна оценка на продуцента и режисьора, взети заедно, с тежест от максимум 12 точки. Комисията дава останалите 88 точки и така един проект може да събере най-много 100 точки. Според методологията на служебната оценка по 0,40 точки получава и филм, гледан от 7500 зрители, и филм, гледан от 750 000 зрители, а не трябва да е така. Към същата служебна оценка може да се добавят до 8 точки за богат фестивален живот на предишни филми на продуцента и режисьора, дори тези продукции да не са стъпвали в нашите кина. В България, а и навън филмите са гледани от незначителен брой зрители, за да имат културно въздействие. Това е грешно. Идеята драстично да се добавят точки при по висок праг на гледаемост е добра, но и опасна при небалансиран подход. 

Основният проблем е, че в ЗФИ няма визия как да се създава добро, но и гледаемо кино –

в него цари хаос, а текстовете са твърде общи. Това даде възможност за десетилетното му натъкмяване чрез лобистки допълнения и тълкувания с наредби, указания, заповеди и правилници за приложение. Там е нужна основна промяна, която да реформира начина на финансиране.

Един от начините за избягване на конфликтите на интереси е мандатността да се превърне в основен принцип. Добре е всяка конкурсна сесия да се ръководи от отделен продуцент, който с екипа си да наблюдава процеса на създаване на филмите до премиерата им. След първите пет или десет седмици от боксофиса той може да кандидатства за следваща сесия. Тези продуценти могат да бъдат класирани по обективни, но и балансирани критерии – боксофис, фестивали и пр. Вярната посока е създаване на разнообразно кинематографично портфолио от български филми за всякакъв тип зрители. 

Бюджетите за маркетинг и реклама трябва да станат част от бюджета на филма.

Зрителят е спечелен. А след това?

След като се произведе боксофис хит, би било полезно да има фонд, от който да се финансира директно част от всеки следващ проект на авторите на успешните филми. Това е основа за устойчиво развитие на продуцентите и ще им позволи да имат бизнес план. Добре е НФЦ да разполага със собствени зали или с верига от киносалони, с които да работи на преференциални цени. Това обаче зависи от държавата и от нейната данъчна политика спрямо собственици и дистрибутори.

Тук искам да направя уточнение: не финансовият успех следва да е водещ за подкрепата на евентуален следващ проект, а сценарият. В Испания например отделен фонд предоставя автоматично – до изчерпването си – субсидия за следващия филм на най-добре представилите се продуценти в боксофис класацията. Това не е основно финансиране, а предпоставка за устойчиво развитие на продуцента и база за формиране на следващ бюджет.

Филмовите теми, властта и прозрачността 

Ако НФЦ започне да продуцира публично финансирани филми, това не означава, че НФЦ трябва да прокарва идеите на властта. Темите и артикулирането им са въпрос на творческа автономия, те следва да са забранена територия за политици и чиновници. Не трябва да залагаме какъв тип или жанр филми да се произвеждат, а да създадем предпоставки да бъдат поощрявани добрите проекти. Един сценарий е добър не ако на оценяващия му харесва, а когато е добре построен и има четлива тема, която не накърнява основни морални ценности. Кои ще бъдат филмите ни, следва да зависи не от личността на членове на комисията, а от творците, каквито ги създава обществото ни. 

В момента членовете на комисии точкуват, сякаш четат книга, която или им допада, или не; харесват или не харесват вносителя на проекта или обкръжението му. Така имат по-голям шанс за финансиране „творците“, яхнали моментната конюнктура, шанс за финансиране, а не добрите проекти.

Сайтът на НФЦ трябва да предлага леснодостъпна информация. В момента е кошмар да работиш със статистиката за боксофиса – тя не само е в екселски файлове, а в имената им има разминавания. Няма бърз достъп до данни за гледаемостта на прожекциите със заглавията на филмите – така информацията по-скоро се крие, отколкото е достъпна.

Българското кинопроизводство през 2050 г.

ЗФИ е обнародван през 2003 г. Член 10, който регламентира каква да е художествената комисия, оценяваща филмите, е изменен веднъж през 2007. В него се коренят раздорите – как се осъществява подборът на проекти за финансиране. Нужен е нов ЗФИ, защото в сегашния му вид в него има стотици намеси на подзаконово ниво, които го правят тромав и неработещ. 

Този закон се променя веднъж на две поколения. Обществените нагласи обаче също се променят. Няма гаранция, че ако днес българската публика иска да гледа филм, в който актьорите дерат ризи и крещят „Аз тези хора няма да ги предам“, след няколко години няма да имат други естетически потребности. Един добър закон е ориентиран към бъдещето. Затова е нужен поглед на визионер, който да остави моментните конюнктурни желания на една или друга група от съсловието настрана и да помисли за идните творци. 

Една сериозна реформа в киното ни ще размести пластовете. Много от сега снимащите колеги ще трябва да се нагодят към обективно оценяване на проектите им. Смисълът е да се върне надеждата в младите, за да повярват, че не с приспособленчество, а с талант и лични усилия могат да осъществят идеите си. С такава промяна киното ни ще е във възход. Имаме нужда от нов ЗФИ с поглед в 2050 г.

Supermicro SYS-112C-TN Review 1P Intel Xeon 6 1U Server

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/supermicro-sys-112c-tn-review-1p-intel-xeon-6-1u-server/

In our Supermicro SYS-112C-TN review, we see how this single-socket Intel Xeon 6 server performs and how it is designed differently

The post Supermicro SYS-112C-TN Review 1P Intel Xeon 6 1U Server appeared first on ServeTheHome.

Anchoring AWS Outposts servers with AWS Direct Connect

Post Syndicated from Art Baudo original https://aws.amazon.com/blogs/compute/anchoring-aws-outposts-servers-with-aws-direct-connect/

This post is written by Perry Wald, Principal GTM SA, Hybrid Edge, Eric Vasquez Senior SA Hybrid Edge, and Fernando Galves Gen AI Solutions Architect, Outposts

AWS Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to customer premises. Outposts servers launched in 2022, a 1U or 2U rack-mountable host, with the ability to run Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Container Service (Amazon ECS), as well as other appropriate smaller scale edge services such as AWS IoT Greengrass. This version of Outposts is primarily focused on bringing lower latency, AWS compute capabilities to the edge at many user locations.

During Outposts provisioning, you or AWS creates a service link connection that connects your Outposts server to your chosen AWS Region or home Region. Outposts depends on regional connectivity “to reach out to home,” needing very little in terms of networking. Looking at the network requirements, it needs:

  • DHCP, to assign an IP address and a default gateway
  • Public DNS, to resolve the name of the initial regional endpoint, to allow automated setup, and
  • Internet access, so that when the regional endpoint has been resolved, the Outpost can reach that endpoint. With a minimum of 500 Mbps or and a max of 175 ms round trip latency

User challenges with internet connectivity at the edge

When you order an Outposts server, you are responsible for installing the server. Outposts servers are self-provisioning and need a service link connection between your Outposts and the AWS Region (or home Region). This connection allows for the management of Outposts and the exchange of traffic to and from the AWS Region. Server deployment can be broken down into the following steps: installing the Outposts servers, powering them on, and providing authentication details through a command line. Then, the Outpost servers reach out to the regional endpoint, and provision themselves. Your Outpost status will show as Active when the process has completed, it could take a few hours depending on service link bandwidth.

Although this has been suitable for the vast majority of use cases, there are some locations that can’t provide internet connectivity in their environments. This has mostly been in use cases where there is a strong security reason for not having an internet connection (such as financial services kiosks, small manufacturing facilities, and defense), so as to avoid risks such as DDoS attacks and potential hack attempts, or to meet requirements for receiving an authority to operate (ATO).

These locations either have some form of direct connect, or more commonly have a centralized direct connect link to AWS, and an MPLS network linking all their remote sites to a central one. In both of these scenarios, the requirement is to allow the Outpost servers to resolve and reach the public endpoint for setup, and subsequently the public anchor endpoint for management. This is done without needing to leave the AWS ecosystem, without needing to expose themselves unnecessarily to potential internet threats, and without adding more systems to manage themselves, but rather making use of AWS services.

To meet this requirement, we identified several key things that need to be provided if the user does not have internet connectivity at the remote location, as follows:

  1. DHCP, to provide the Outposts servers with an IP address, default gateway, and DNS servers.
  2. Public DNS access to resolve both the setup endpoint, and when live, the anchor endpoint.
  3. Public internet access, without exposing the user location to potentially harmful traffic from the internet.

Direct Connect VIF options

There are three different types of Virtual Interfaces (VIF) possible to configure on an AWS Direct Connect link:

  • Public VIF: A public VIF can access all AWS public services using public IP addresses.
  • Private VIF: A private VIF should be used to access an Amazon Virtual Private Cloud (Amazon VPC) using private IP addresses.
  • Transit VIF: A transit VIF should be used to access one or more Amazon VPC Transit Gateways associated with Direct Connect gateways.

Transit VIF option

A transit VIF can be used to solve both of these issues. First, a transit VIF deploys an ENI within a VPC (known as an attachment), so that traffic coming from the transit VIF into a VPC can be routed. This is because it follows the rule that, for non-transitive VPC routing, the traffic has to either be sourced or targeted for an ENI in the VPC.

If the traffic is forwarded to a regional VPC through the transit gateway, then it can be forwarded to the internet through an NAT gateway. This is an enhancement of the architecture to use a transit gateway to provide a single egress point for multiple VPCs to the internet. For more information, see Creating a single internet exit point from multiple VPCs Using AWS Transit Gateway. In this case, instead of the transit gateway routing multiple VPCs to the internet, it’s routing to an on-premises connection.

Using a transit gateway to forward traffic to an NAT gateway allows you to provide internet connectivity for the Outposts servers without managing virtual appliances, because NAT gateway provides this as a service. NAT gateways also only allow outbound access, so they provide security against any attempted external access by a bad actor from the internet. This works for Outposts servers since they only need outbound access. Outposts always initiate communication to an anchor or service endpoint, and they never receive communication except as a response.

Architectural diagram showing the use of a Transit VIF and NAT gateway in a Region reaching regional endpoints

Figure 1. Architectural diagram showing the use of a Transit VIF and NAT gateway in a Region reaching regional endpoints

DNS provisioning

Although the preceding architecture solves the challenge of how we provide a path for IP packets to transit between the Outposts servers and the public endpoints needed, it doesn’t solve the issue of resolving DNS names. If the remote site is isolated from the internet, then it has no clear way to resolve DNS.

Amazon Route53 resolver endpoints allow you to deploy an IP address within a VPC subnet, which provides DNS resolution. There are two types of resolver endpoints: outbound and inbound.

Outbound resolver endpoints are used by AWS to send DNS queries to your on-premises DNS servers. Inbound resolver endpoints are used by your DNS servers (and hosts) to resolve addresses within Route 53.

Route 53 can resolve public DNS names, so the Outposts service endpoint outposts.<region-name>.amazonaws.com becomes resolvable by an inbound resolver endpoint.

Configuring the Outposts egress VPC

  1. Set up service link egress VPC, build subnets, deploy a NAT gateway, and transit gateway.
  2. Create Route 53 resolver inbound endpoint.
  3. Configure DHCP on the switch, and make sure that the DNS value matches resolver endpoint.
  4. Configure Transit VIF on the switch, build a BGP peer, and attach to your transit gateway.
  5. Confirm propagation settings on transit gateway and default routes.
  6. Confirm routes on subnets to allow traffic out to the internet, and back to your Outpost servers.
  7. Test name resolution (dig) and https (curl) test to service endpoint.
  8. If needed, install your Outpost servers.

Public VIF option

Using a public VIF allows you to provide an internet connection directly to the on-premises site. In turn, this means you need to implement firewalls and security functions on this connection, adding more layers of operational overhead. A public VIF also means that the on-premises end of the VIF can be accessed by any public IP on the AWS public network, regardless of the instance to which IP is mapped. A public VIF is a public IP endpoint on the AWS public network. You should treat public VIF traffic as internet-based traffic. This can become cumbersome for firewalls teams if they have to allow-list known AWS IP ranges and manage the stateful firewall for a long range of AWS IPs.

Furthermore, even if the user is happy to implement and manage a firewall on the end of that public VIF, there is still a question of how the Outpost would resolve DNS in this setup, and subsequent anchor endpoints. Unless the private network already has DNS resolution to a public DNS, then there are no DNS servers that DHCP can point to in order to allow the Outposts servers to get name resolution. This is because there is no public DNS endpoint within the AWS public network. Traffic from a user’s public VIF can access the AWS public network, but it can’t exit it to other public networks. For example, if the you had configured DHCP to point to one of the well-known DNS servers (such as 8.8.8.8), then, since this DNS servers lives outside of the AWS public network, requests originating from the on-premises side of a public VIF would be dropped as it hit the border of the AWS autonomous system.

The only way for a DNS request to be resolved would be to build a bind forwarding service within a VPC, provide it with a public IP address, and point the DHCP DNS values at this IP address.

This network configuration introduces complexity, and won’t be possible for those with highly regulated workloads. You would need to manage a firewall on-premises, allow a public network to reach the on-premises location, and manage a bind servers setup within a VPC. For these reasons, a public VIF is generally not an option unless the user is already running one, and is familiar with the steps to secure it.

Figure 2. Architectural diagram showing traffic flow using a public VIF and AWS Outposts

Private VIF option

A private VIF whether connected directly to a virtual private gateway (VGW), or through a Direct Connect gateway. VPCs do not support transitive routing. To explain this another way, any traffic following a routing rule in a subnet route table has to either originate from, or be destined for, an IP address (or to be more explicit, an Elastic Network Interface (ENI)) inside that VPC.

Virtual private gateways do not have an ENI associated with them, but are pointed to as a next hop within a subnet routing table. If we take this example and look at what the Outposts servers would be trying to pass as traffic, then it would send a packet with a source address of the Outposts servers, and a destination address of the Outposts service public endpoint (assuming that it could resolve it). When this packet reaches the VPC, then neither the source nor destination address would belong to an ENI within the VPC. Therefore, VPC routing would drop the packet.

Even if there was a routing rule on the subnet pointing the next hop for all traffic to a NAT gateway (ideal for internet egress), the routing still wouldn’t work. This is because the packet from the Outposts servers doesn’t have a destination of the NAT gateway, but instead a destination of the setup endpoint in the internet.

It’s possible to use a combination of ingress routing and transparent proxies to ingest the traffic and pass it to an instance running a proxy service to forward to the internet. However, this adds complexity having to manage and maintain proxy servers. For these reasons, a private VIF is generally not recommended.

Architectural diagram showing VGW and packet drops because of transitive routing not being supported

Figure 3. Architectural diagram showing VGW and packet drops because of transitive routing not being supported

Conclusion

In this post, we discussed architecture patterns you can use to provision your Outposts when public internet connectivity is unavailable. To get started with Outpost servers please visit our Server User Guide. For more information, contact us to learn more.

[$] Improving the merging of anonymous VMAs

Post Syndicated from corbet original https://lwn.net/Articles/1015762/

The virtual memory area (VMA), represented by struct
vm_area_struct
, is one of the core abstractions of the kernel’s
memory-management subsystem; a VMA represents a portion of a process’s
address space with the same characteristics. A memory-mapped file will be
represented by (at least) one VMA, as will the process’s stack or a region
of anonymous memory. Efficiently managing VMAs and the logic around them
is crucial for good performance overall. Lorenzo Stoakes focused on one
specific problem area: the merging of anonymous VMAs, during the
memory-management track at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit.

The collective thoughts of the interwebz