Beginning on Thursday, November 2, 2023 at 11:43 UTC Cloudflare’s control plane and analytics services experienced an outage. The control plane of Cloudflare consists primarily of the customer-facing interface for all of our services including our website and APIs. Our analytics services include logging and analytics reporting.

The incident lasted from November 2 at 11:44 UTC until November 4 at 04:25 UTC. We were able to restore most of our control plane at our disaster recovery facility as of November 2 at 17:57 UTC. Many customers would not have experienced issues with most of our products after the disaster recovery facility came online. However, other services took longer to restore and customers that used them may have seen issues until we fully resolved the incident. Our raw log services were unavailable for most customers for the duration of the incident.

Services have now been restored for all customers. Throughout the incident, Cloudflare’s network and security services continued to work as expected. While there were periods where customers were unable to make changes to those services, traffic through our network was not impacted.

This post outlines the events that caused this incident, the architecture we had in place to prevent issues like this, what failed, what worked and why, and the changes we’re making based on what we’ve learned over the last 36 hours.

To start, this never should have happened. We believed that we had high availability systems in place that should have stopped an outage like this, even when one of our core data center providers failed catastrophically. And, while many systems did remain online as designed, some critical systems had non-obvious dependencies that made them unavailable. I am sorry and embarrassed for this incident and the pain that it caused our customers and our team.

Intended Design

Cloudflare’s control plane and analytics systems run primarily on servers in three data centers around Hillsboro, Oregon. The three data centers are independent of one another, each have multiple utility power feeds, and each have multiple redundant and independent network connections.

The facilities were intentionally chosen to be at a distance apart that would minimize the chances that a natural disaster would cause all three to be impacted, while still close enough that they could all run active-active redundant data clusters. This means that they are continuously syncing data between the three facilities. By design, if any of the facilities goes offline then the remaining ones are able to continue to operate.

This is a system design that we began implementing four years ago. While most of our critical control plane systems had been migrated to the high availability cluster, some services, especially for some newer products, had not yet been added to the high availability cluster.

In addition, our logging systems were intentionally not part of the high availability cluster. The logic of that decision was that logging was already a distributed problem where logs were queued at the edge of our network and then sent back to the core in Oregon (or another regional facility for customers using regional services for logging). If our logging facility was offline then analytics logs would queue at the edge of our network until it came back online. We determined that analytics being delayed was acceptable.

Flexential Data Center Power Failure

The largest of the three facilities in Oregon is run by Flexential. We refer to this facility as “PDX-04.” Cloudflare leases space in PDX-04 where we house our largest analytics cluster as well as more than a third of the machines for our high availability cluster. It is also the default location for services that have not yet been onboarded onto our high availability cluster. We are a relatively large customer of the facility, consuming approximately 10 percent of its total capacity.

On November 2 at 08:50 UTC Portland General Electric (PGE), the utility company that services PDX-04, had an unplanned maintenance event affecting one of their independent power feeds into the building. That event shut down one feed into PDX-04. The data center has multiple feeds with some level of independence that can power the facility. However, Flexential powered up their generators to effectively supplement the feed that was down.

Counter to best practices, Flexential did not inform Cloudflare that they had failed over to generator power. None of our observability tools were able to detect that the source of power had changed. Had they informed us, we would have stood up a team to monitor the facility closely and move control plane services that were dependent on that facility out while it was degraded.

It is also unusual that Flexential ran both the one remaining utility feed and the generators at the same time. It is not unusual for utilities to ask data centers to drop off the grid when power demands are high and run exclusively on generators. Flexential operates 10 generators, inclusive of redundant units, capable of supporting the facility at full load. It would also have been possible for Flexential to run the facility only from the remaining utility feed. We haven’t gotten a clear answer why they ran utility power and generator power.

Informed Speculation On What Happened Next

From this decision onward, we don’t yet have clarity from Flexential on the root cause or some of the decisions they made or the events. We will update this post as we get more information from Flexential, as well as PGE, on what happened. Some of what follows is informed speculation based on the most likely series of events as well as what individual Flexential employees have shared with us unofficially.

One possible reason they may have left the utility line running is because Flexential was part of a program with PGE called DSG. DSG allows the local utility to run a data center’s generators to help supply additional power to the grid. In exchange, the power company helps maintain the generators and supplies fuel. We have been unable to locate any record of Flexential informing us about the DSG program. We’ve asked if DSG was active at the time and have not received an answer. We do not know if it contributed to the decisions that Flexential made, but it could explain why the utility line continued to remain online after the generators were started.

At approximately 11:40 UTC, there was a ground fault on a PGE transformer at PDX-04. We believe, but have not been able to get confirmation from Flexential or PGE, that this was the transformer that stepped down power from the grid for the second feed that was still running as it entered the data center. It seems likely, though we have not been able to confirm with Flexential or PGE, that the ground fault was caused by the unplanned maintenance PGE was performing that impacted the first feed. Or it was a very unlucky coincidence.

Ground faults with high voltage (12,470 volt) power lines are very bad. Electrical systems are designed to quickly shut down to prevent damage when one occurs. Unfortunately, in this case, the protective measure also shut down all of PDX-04’s generators. This meant that the two sources of power generation for the facility — both the redundant utility lines as well as the 10 generators — were offline.

Fortunately, in addition to the generators, PDX-04 also contains a bank of UPS batteries. These batteries are supposedly sufficient to power the facility for approximately 10 minutes. That time is meant to be enough to bridge the gap between the power going out and the generators automatically starting up. If Flexential could get the generators or a utility feed restored within 10 minutes then there would be no interruption. In reality, the batteries started to fail after only 4 minutes based on what we observed from our own equipment failing. And it took Flexential far longer than 10 minutes to get the generators restored.

Attempting to Restore Power

While we haven’t gotten official confirmation, we have been told by employees that three things hampered getting the generators back online. First, they needed to be physically accessed and manually restarted because of the way the ground fault had tripped circuits. Second, Flexential’s access control system was not powered by the battery backups so it was offline. And third, the overnight staffing at the site did not include an experienced operations or electrical expert — the overnight shift consisted of security and an unaccompanied technician who had only been on the job for a week.

Between 11:44 and 12:01 UTC, with the generators not fully restarted, the UPS batteries ran out of power and all customers of the data center lost power. Throughout this, Flexential never informed Cloudflare that there was any issue at the facility. We were first notified of issues in the data center when the two routers that connect the facility to the rest of the world went offline at 11:44 UTC. When we weren’t able to reach the routers directly or through out-of-band management, we attempted to contact Flexential and dispatched our local team to physically travel to the facility. The first message to us from Flexential that they were experiencing an issue was at 12:28 UTC.

We are currently experiencing an issue with power at our [PDX-04] that began at approximately 0500AM PT [12:00 UTC]. Engineers are actively working to resolve the issue and restore service. We will communicate progress every 30 minutes or as more information becomes available as to the estimated time to restore. Thank you for your patience and understanding.

Designing for Data Center Level Failure

While the PDX-04’s design was certified Tier III before construction and is expected to provide high availability SLAs, we planned for the possibility that it could go offline. Even well-run facilities can have bad days. And we planned for that. What we expected would happen in that case is that our analytics would be offline, logs would be queued at the edge and delayed, and certain lower priority services that were not integrated into our high availability cluster would go offline temporarily until they could be restored at another facility.

The other two data centers running in the area would take over responsibility for the high availability cluster and keep critical services online. Generally that worked as planned. Unfortunately, we discovered that a subset of services that were supposed to be on the high availability cluster had dependencies on services exclusively running in PDX-04.

In particular, two critical services that process logs and power our analytics — Kafka and ClickHouse — were only available in PDX-04 but had services that depended on them that were running in the high availability cluster. Those dependencies shouldn’t have been so tight, should have failed more gracefully, and we should have caught them.

We had performed testing of our high availability cluster by taking offline each (and both) of the other two data center facilities entirely offline. And we had also tested taking the high availability portion of PDX-04 offline. However, we had never tested fully taking the entire PDX-04 facility offline. As a result, we had missed the importance of some of these dependencies on our data plane.

We were also far too lax about requiring new products and their associated databases to integrate with the high availability cluster. Cloudflare allows multiple teams to innovate quickly. As such, products often take different paths toward their initial alpha. While, over time, our practice is to migrate the backend for these services to our best practices, we did not formally require that before products were declared generally available (GA). That was a mistake as it meant that the redundancy protections we had in place worked inconsistently depending on the product.

Moreover, far too many of our services depend on the availability of our core facilities. While this is the way a lot of software services are created, it does not play to Cloudflare’s strength. We are good at distributed systems. Throughout this incident, our global network continued to perform as expected. While some of our products and features are configurable and serviceable through the edge of our network without needing the core, far too many today fail if the core is unavailable. We need to use the distributed systems products that we make available to all our customers for all our services so they continue to function mostly as normal even if our core facilities are disrupted.

Disaster Recovery

At 12:48 UTC, Flexential was able to get the generators restarted. Power returned to portions of the facility. In order to not overwhelm the system, when power is restored to a data center it is typically done gradually by powering back on one circuit at a time. Like the circuit breakers in a residential home, each customer is serviced by redundant breakers. When Flexential attempted to power back up Cloudflare’s circuits, the circuit breakers were discovered to be faulty. We don’t know if the breakers failed due to the ground fault or some other surge as a result of the incident, or if they’d been bad before and it was only discovered after they had been powered off.

Flexential began the process of replacing the failed breakers. That required them to source new breakers because more were bad than they had on hand in the facility. Because more services were offline than we expected, and because Flexential could not give us a time for restoration of our services, we made the call at 13:40 UTC to fail over to Cloudflare’s disaster recovery sites located in Europe. Thankfully, we only needed to fail over a small percentage of Cloudflare’s overall control plane. Most of our services continued to run across our high availability systems across the two active core data centers.

We turned up the first services on the disaster recovery site at 13:43 UTC.Cloudflare’s disaster recovery sites provide critical control plane services in the event of a disaster. While the disaster recovery site does not support some of our log processing services, it is designed to support the other portions of our control plane.

When services were turned up there, we experienced a thundering herd problem where the API calls that had been failing overwhelmed our services. We implemented rate limits to get the request volume under control. During this period, customers of most products would have seen intermittent errors when making modifications through our dashboard or API. By 17:57 UTC, the services that had been successfully moved to the disaster recovery site were stable and most customers were no longer directly impacted. However, some systems still required manual configuration (e.g., Magic WAN) and some other services, largely related to log processing and some bespoke APIs, remained unavailable until we were able to restore PDX-04.

Some Products and Features Delayed Restart

A handful of products did not properly get stood up on our disaster recovery sites. These tended to be newer products where we had not fully implemented and tested a disaster recovery procedure. These included our Stream service for uploading new videos and some other services. Our team worked two simultaneous tracks to get these services restored: 1) reimplementing them on our disaster recovery sites; and 2) migrating them to our high-availability cluster.

Flexential replaced our failed circuit breakers, restored both utility feeds, and confirmed clean power at 22:48 UTC. Our team was all-hands-on-deck and had worked all day on the emergency, so I made the call that most of us should get some rest and start the move back to PDX-04 in the morning. That decision delayed our full recovery, but I believe made it less likely that we’d compound this situation with additional mistakes.

Beginning first thing on November 3, our team began restoring service in PDX-04. That began with physically booting our network gear then powering up thousands of servers and restoring their services. The state of our services in the data center was unknown as we believed multiple power cycles were likely to have occurred during the incident. Our only safe process to recover was to follow a complete bootstrap of the entire facility.

This involved a manual process of bringing our configuration management servers online to begin the restoration of the facility. Rebuilding these took 3 hours. From there, our team was able to bootstrap the rebuild of the rest of the servers that power our services. Each server took between 10 minutes and 2 hours to rebuild. While we were able to run this in parallel across multiple servers, there were inherent dependencies between services that required some to be brought back online in sequence.

Services are now fully restored as of November 4 at 04:25 UTC. For most customers, because of how we queue analytics at the edge, you should see no data loss in your analytics. Any gaps that appear as of now we expect will fill in as any lingering caches of analytics data is ingested. For customers that use our log push feature, your logs will not have been processed for the majority of the event, so anything you did not receive will not be recovered. However, the records in our analytics dashboard will still be accurate.

Lessons and Remediation

We have a number of questions that we need answered from Flexential. But we also must expect that entire data centers may fail. Google has a process where when there’s a significant event or crisis they can call a Code Yellow or Code Red. In these cases, most or all engineering resources are shifted to addressing the issue at hand.

We have not had such a process in the past, but it’s clear today we need to implement a version of it ourselves: Code Orange. We are shifting all non-critical engineering functions to focusing on ensuring high reliability of our control plane. As part of that, we expect the following changes:

Remove dependencies on our core data centers for control plane configuration of all services and move them wherever possible to be powered first by our distributed network
Ensure that the control plane running on the network continues to function even if all our core data centers are offline
Require that all products and features that are designated Generally Available must rely on the high availability cluster (if they rely on any of our core data centers), without having any software dependencies on specific facilities
Require all products and features that are designated Generally Available have a reliable disaster recovery plan that is tested
Test the blast radius of system failures and minimize the number of services that are impacted by a failure
Implement more rigorous chaos testing of all data center functions including the full removal of each of our core data center facilities
Thorough auditing of all core data centers and a plan to reaudit to ensure they comply with our standards
Logging and analytics disaster recovery plan that ensures no logs are dropped even in the case of a failure of all our core facilities

As I said earlier, I am sorry and embarrassed for this incident and the pain that it caused our customers and our team. We have the right systems and procedures in place to be able to withstand even the cascading string of failures we saw at our data center provider, but we need to be more rigorous about enforcing that they are followed and tested for unknown dependencies. This will have my full attention and the attention of a large portion of our team through the balance of the year. And the pain from the last couple days will make us better.

Седмицата (30 октомври – 4 ноември)

2023-11-04 Боряна Телбис

Post Syndicated from Боряна Телбис original https://www.toest.bg/sedmitsata-30-oktomvri-4-noemvri/

Човекът е най-безпомощният бозайник. При раждането си човешкото бебе не вижда добре, не се движи кой знае колко успешно, дори главата си не може да държи изправена. Прохожда и проговаря около и след първата година – на тази възраст повечето други бозайници вече се придвижват и се хранят сами. Накратко, за да оцелее, човекът е тежко зависим от други хора.

Пак да го кажа: за да го има на този свят, човекът зависи от човека.

Тогава защо е този глобален зор да се мразим и избиваме по най-различни начини? И тук въобще не искам да влизам в някакъв неохипарски дискурс, в който всички сме цветя, живеем в мир и светлина и сме добри, та добри. Съвсем практично е: колкото по-малко се тормозим едни други, толкова по-добре за децата ни; толкова повече от тях ще оцелеят. Защото мен лично в момента ме е срам пред децата ми – че възрастните в този свят го добутаха до това положение. И ме е страх по същата причина. Колко от вас изпитват вина, когато прегърнат детето си, защото са го довели в свят, който с всеки изминал ден става все по-зле? Толкова зле, че тази седмица Иван Костов си позволи да го сравни с времената непосредствено преди Първата световна война.

За добро или за лошо, всичко зависи от нас и от изборите, които правим.

И седмицата в „Тоест“ започна с избори. Яна Хашъмова обърна погледа ни към гласуването в САЩ и Полша, което привидно няма нищо общо с нашето, но всъщност се оказва, че някои неща са едни и същи навсякъде по света. Емилия Милчева прави сравнение между двамата кандидати, които утре ще бъдат на балотаж за кмет на столицата. Двама души, родени в София през 1978 г., с различен старт, социален бекграунд и умения. Два свята, които в идеалния вариант може би се срещат някъде. Но идеален вариант няма, така че изборът на 5 ноември е неизбежен, пише Емилия.

За кризата, в която се намира светът, говори и Галин Стоев пред Стефан Иванов в интервю, което „Тоест“ публикува съвсем тематично в Деня на народните будители.

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

„Времената на криза не търпят вакуум. Думи винаги трябват. Въпросът е кой говори“, пише Йоанна Елми в текста си „Има ли право Палестина на литература?“. В него тя разглежда въпроса с отмененото награждаване на палестинската писателка Адания Шибли и с все по-утежняващата обстоятелствата склонност на обществата да се разделят на „за“ и „против“ около някаква виртуална арена, върху която умират истински хора.

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

Липсата на информираност и образование, която може да те доведе до безпомощност и истинска безизходица, е темата в текста на Мирела Петкова. С „Всеки има право на образование“ продължаваме поредицата за ранната бременност и ефектите от нея върху твърде много съдби – повече, отколкото маргиналността на проблема предполага на първо четене.

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

Антония Апостолова има още един текст в тазседмичния „Тоест“ и в него също по някакъв начин става дума за „подробностите“. Тя разговаря с поета Георги Гаврилов за новата му книга и за всичко случващо се в света. Прочетете това интервю, както и всичко в „Тоест“ от тази седмица. Оставям ви на собствените ви избори и житейски подробности с кратък откъс от разговора на Антония и Георги:

3 сутринта е часът, който се споменава непрекъснато в книгата. Какво ще се случи тогава?

3 сутринта е символ на времето, когато не би трябвало нищо да се променя. Лично аз винаги съм го възприемал като момент, в който светът спи, хората спят – добри, лоши, всякакви, – просто спят, денят е свършил, новините са се изчерпали и няма нищо повече. Ето това изгубено спокойствие на 3 сутринта ми липсва от известно време насам. Вече нямаме „час на нищото“ и това е изнервящо.

7StarLake TEC300S Ampere Altra Passively Cooled System at OCP Summit 2023

2023-11-04 John Lee

Post Syndicated from John Lee original https://www.servethehome.com/7starlake-tec300s-ampere-altra-passively-cooled-system-at-ocp-summit-2023/

We saw the 7StarLake TEC300S at OCP Summit 2023. This rugged and passively cooled system can handle 128 cores, 2TB of memory, and even a GPU

The post 7StarLake TEC300S Ampere Altra Passively Cooled System at OCP Summit 2023 appeared first on ServeTheHome.

Comic for 2023.11.04 – Baggy

2023-11-04 Explosm.net

Post Syndicated from Explosm.net original https://explosm.net/comics/baggy

New Cyanide and Happiness Comic

Streaming SQL in Data Mesh

2023-11-03 Netflix Technology Blog

Post Syndicated from Netflix Technology Blog original https://netflixtechblog.com/streaming-sql-in-data-mesh-0d83f5a00d08

Democratizing Stream Processing @ Netflix

By Guil Pires, Mark Cho, Mingliang Liu, Sujay Jain

Data powers much of what we do at Netflix. On the Data Platform team, we build the infrastructure used across the company to process data at scale.

In our last blog post, we introduced “Data Mesh” — A Data Movement and Processing Platform. When a user wants to leverage Data Mesh to move and transform data, they start by creating a new Data Mesh pipeline. The pipeline is composed of individual “Processors” that are connected by Kafka topics. The Processors themselves are implemented as Flink jobs that use the DataStream API.

Since then, we have seen many use cases (including Netflix Graph Search) adopt Data Mesh for stream processing. We were able to onboard many of these use cases by offering some commonly used Processors out of the box, such as Projection, Filtering, Unioning, and Field Renaming.

An example of a Data Mesh pipeline which moves and transforms data using Union, GraphQL Enrichment, and Column Rename Processor before writing to an Iceberg table.

By keeping the logic of individual Processors simple, it allowed them to be reusable so we could centrally manage and operate them at scale. It also allowed them to be composable, so users could combine the different Processors to express the logic they needed.

However, this design decision led to a different set of challenges.

Some teams found the provided building blocks were not expressive enough. For use cases which were not solvable using existing Processors, users had to express their business logic by building a custom Processor. To do this, they had to use the low-level DataStream API from Flink and the Data Mesh SDK, which came with a steep learning curve. After it was built, they also had to operate the custom Processors themselves.

Furthermore, many pipelines needed to be composed of multiple Processors. Since each Processor was implemented as a Flink Job connected by Kafka topics, it meant there was a relatively high runtime overhead cost for many pipelines.

We explored various options to solve these challenges, and eventually landed on building the Data Mesh SQL Processor that would provide additional flexibility for expressing users’ business logic.

The existing Data Mesh Processors have a lot of overlap with SQL. For example, filtering and projection can be expressed in SQL through SELECT and WHERE clauses. Additionally, instead of implementing business logic by composing multiple individual Processors together, users could express their logic in a single SQL query, avoiding the additional resource and latency overhead that came from multiple Flink jobs and Kafka topics. Furthermore, SQL can support User Defined Functions (UDFs) and custom connectors for lookup joins, which can be used to extend expressiveness.

Data Mesh SQL Processor

Since Data Mesh Processors are built on top of Flink, it made sense to consider using Flink SQL instead of continuing to build additional Processors for every transform operation we needed to support.

The Data Mesh SQL Processor is a platform-managed, parameterized Flink Job that takes schematized sources and a Flink SQL query that will be executed against those sources. By leveraging Flink SQL within a Data Mesh Processor, we were able to support the streaming SQL functionality without changing the architecture of Data Mesh.

Underneath the hood, the Data Mesh SQL Processor is implemented using Flink’s Table API, which provides a powerful abstraction to convert between DataStreams and Dynamic Tables. Based on the sources that the processor is connected to, the SQL Processor will automatically convert the upstream sources as tables within Flink’s SQL engine. User’s query is then registered with the SQL engine and translated into a Flink job graph consisting of physical operators that can be executed on a Flink cluster. Unlike the low-level DataStream API, users do not have to manually build a job graph using low-level operators, as this is all managed by Flink’s SQL engine.

SQL Experience on Data Mesh

The SQL Processor enables users to fully leverage the capabilities of the Data Mesh platform. This includes features such as autoscaling, the ability to manage pipelines declaratively via Infrastructure as Code, and a rich connector ecosystem.

In order to ensure a seamless user experience, we’ve enhanced the Data Mesh platform with SQL-centric features. These enhancements include an Interactive Query Mode, real-time query validation, and automated schema inference.

To understand how these features help the users be more productive, let’s take a look at a typical user workflow when using the Data Mesh SQL Processor.

Users start their journey by live sampling their upstream data sources using the Interactive Query Mode.
As the user iterate on their SQL query, the query validation service provides real-time feedback about the query.
With a valid query, users can leverage the Interactive Query Mode again to execute the query and get the live results streamed back to the UI within seconds.
For more efficient schema management and evolution, the platform will automatically infer the output schema based on the fields selected by the SQL query.
Once the user is done editing their query, it is saved to the Data Mesh Pipeline, which will then be deployed as a long running, streaming SQL job.

*Overview of the SQL Processor workflow.*

Users typically iterate on their SQL query multiple times before deploying it. Validating and analyzing queries at runtime after deployment will not only slow down their iteration, but also make it difficult to automate schema evolution in Data Mesh.

To address this challenge, we have implemented a query validation service that can verify a Flink SQL query and provide a meaningful error message for violations in real time. This enables users to have prompt validation feedback while they are editing the query. We leverage Apache Flink’s internal Planner classes to parse and transform SQL queries without creating a fully-fledged streaming table environment. This makes the query service lightweight, scalable, and execution agnostic.

To effectively operate thousands of use cases at the platform layer, we built opinionated guardrails to limit some functionalities of Flink SQL. We plan on gradually expanding the supported capabilities over time. We implemented the guardrails by recursively inspecting the Calcite tree constructed from user’s query. If the tree contains nodes that we currently don’t support, the query will be rejected from being deployed. Additionally, we translate Flink’s internal exceptions containing cryptic error messages into more meaningful error messages for our users. We plan on continuing our investments into improving the guardrails, as having proper guardrails help to improve the user experience. Some ideas for the future include rules to reject expensive and suboptimal queries.

To help Data Mesh users iterate quickly on their business logic, we have built the Interactive Query Mode as part of the platform. Users can start live sampling their streaming data by executing a simple `SELECT * FROM <table>` query. Using the Interactive Query Mode, Data Mesh platform will execute the Flink SQL query and display the results in the UI in seconds. Since this is a Flink SQL query on streaming data, new results will continue to be delivered to the user in real-time.

Users can continue to iterate and modify their Flink SQL query and once they’re satisfied with their query output, they can save the query as part of their stream processing pipeline.

To provide this interactive experience, we maintain an always-running Flink Session Cluster that can run concurrent parameterized queries. These queries will output their data to a Mantis sink in order to stream the results back to the user’s browser.

An animated gif showing the interactive query mode in action — *Interactive Query mode in action*

Learnings from our journey

In hindsight, we wish we had invested in enabling Flink SQL on the DataMesh platform much earlier. If we had the Data Mesh SQL Processor earlier, we would’ve been able to avoid spending engineering resources to build smaller building blocks such as the Union Processor, Column Rename Processor, Projection and Filtering Processor.

Since we’ve productionized Data Mesh SQL Processor, we’ve seen excitement and quick adoption from our Data Mesh users. Thanks to the flexibility of Flink SQL, users have a new way to express their streaming transformation logic other than writing a custom processor using the low-level DataStream API.

While Flink SQL is a powerful tool, we view the Data Mesh SQL Processor as a complimentary addition to our platform. It is not meant to be a replacement for custom processors and Flink jobs using low-level DataStream API. Since SQL is a higher-level abstraction, users no longer have control over low-level Flink operators and state. This means that if state evolution is critical to the user’s business logic, then having complete control over the state can only be done through low-level abstractions like the DataStream API. Even with this limitation, we have seen that there are many new use cases that are unlocked through the Data Mesh SQL Processor.

Our early investment in guardrails has helped set clear expectations with our users and keep the operational burden manageable. It has allowed us to productionize queries and patterns that we are confident about supporting, while providing a framework to introduce new capabilities gradually.

Future of SQL on Data Mesh

While introducing the SQL Processor to the Data Mesh platform was a great step forward, we still have much more work to do in order to unlock the power of stream processing at Netflix. We’ve been working with our partner teams to prioritize and build the next set of features to extend the SQL Processor. These include stream enrichment using Slowly-Changing-Dimension (SCD) tables, temporal joins, and windowed aggregations.

Stay tuned for more updates!

Streaming SQL in Data Mesh was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Friday Squid Blogging: Eating Dancing Squid

2023-11-03 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/11/friday-squid-blogging-eating-dancing-squid.html

It’s not actually alive, but it twitches in response to soy sauce.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Read my blog posting guidelines here.

Metasploit Weekly Wrap-Up

2023-11-03 Dean Welch

Post Syndicated from Dean Welch original https://blog.rapid7.com/2023/11/03/metasploit-weekly-wrap-up-34/

PTT for DCSync

Metasploit Weekly Wrap-Up

This week, community member smashery made an improvement to the windows_secrets_dump module to enable it to dump domain hashes using the DCSync method after having authenticated with a Kerberos ticket. Now, if a user has a valid Kerberos ticket for a privileged account, they can run the windows_secrets_dump module with the DOMAIN action and obtain the desired information. No password required. This is particularly useful in workflows involving the exploitation of AD/CS, using the ESC family of techniques.

New module content (2)

Citrix ADC (NetScaler) Bleed Scanner

Authors: Dylan Pindur and Spencer McIntyre
Type: Auxiliary
Pull request: #18492 contributed by zeroSteiner
Path: scanner/http/citrix_bleed_cve_2023_4966

Description: This adds a scanner module for exploiting CVE-2023-4966 which is a memory leak in Citrix ADC servers. This vulnerability allows a remote, unauthenticated attacker to leak memory by sending a very large HTTP Host header. The leaked memory is then scanned for session cookies which can be hijacked if found.

F5 BIG-IP TMUI AJP Smuggling RCE

Authors: Michael Weber, Sandeep Singh, Spencer McIntyre, and Thomas Hendrickson
Type: Exploit
Pull request: #18497 contributed by zeroSteiner
Path: linux/http/f5_bigip_tmui_rce_cve_2023_46747

Description: This module exploits a flaw in F5s BIG-IP Traffic Management User Interface (TMUI) that enables an external, unauthenticated attacker to create an administrative user. The attacker can then use the admin user to execute arbitrary code in the context of the root user.

Enhancements and features (3)

#18386 from e-lliot – :
This adds the lmkdir command to Meterpreter, which creates a directory on the local host.
#18441 from sjanusz-r7 – Adds at rest encryption to Meterpreter payloads on the Metasploit host machine’s file system.
#18419 from smashery – This updates the windows_secrets_dump module’s DCSync technique (the DOMAIN action) to use Kerberos tickets for authentication. Users can now use Kerberos tickets for authentication with all actions in the module.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).

На второ четене: „Неясните очертания на света“

2023-11-03

Post Syndicated from original https://www.toest.bg/na-vtoro-chetene-neyasnite-ochertaniya-na-sveta/

„Неясните очертания на света“ от Ирис Волф

На второ четене: „Неясните очертания на света“

превод от немски Виолета Вичева, изд. „Аквариус“, 2022

Има книги, за които сякаш не може да бъде казано нищо и които тъкмо поради това трябва да бъдат прочетени. Макар да не обичам разтегливото определение „тих роман“, „Неясните очертания на света“ е тъкмо такова четиво. Качество, което дели с други подобни книги в чудесното портфолио на издателството (като например „Цял един живот“ на Роберт Зееталер, „Лято в Бурландия“ на Момчил Миланов или „Т. Сингер“ на Даг Сулста, които също препоръчваме – може да прочетете за тях и в „Литературни разговори“).

Този тип текстове разказват цял един живот (а тук всъщност няколко) и цели исторически периоди, само че не по епичен, исторически утежнен, документален начин, а по интимен, задушевен, косвен. Макар предвидимо да бива описван като семейна сага за живота в комунистическа Източна Европа и за последвалата емиграция на Запад, романът на родената в Румъния и емигрирала в Германия като дете Ирис Волф е повече екзистенциален, отколкото исторически, по-скоро камерен, отколкото мащабен.

Да, големите събития и личности, своеобразните жалони на времето са споменати (управлението на крал Михай I, дейността на тайните служби, падането на Берлинската стена, убийството на Чаушеску и съпругата му), но те не са обект на разказа, а негов дискретно щрихиран фон. На много малко места Волф допуска грешката да бъде обяснително-дидактична или сантиментална (все пак пише предимно за чужда на събитията публика), но навсякъде другаде тя не само не преекспонира социално-политическата среда, а я удържа за сметка на крайно личните истории, белязани от базовите житейски, почти ритуални по същността си преживявания: раждането, смъртта, влюбването, жертвата, загубата, приятелството, отпътуването и завръщането.

И все пак факт е, че сюжетът обхваща много десетилетия и няколко поколения, както и два основни топоса – румънската област Банат и Западна Германия. Ирис Волф започва разказа си от 70-те години в банатската провинция, за да се върне във времето преди установяването на комунистическия режим, а след това обратно към годините малко преди и след краха му, та чак до наши дни.

Банат – област, която се поделя между няколко съседни страни – е герой сама по себе си със своята природа, особености и етнически, религиозно и езиково пъстро население: румънци, шваби, унгарци, словаци. И макар само част от действието да се развива там, то за Волф именно

на това място се определяше какво е щастие, какво е свобода.

На второ четене: „Неясните очертания на света“

Романът е съставен от седем глави, като всяка предоставя гледната точка в трето лице на герой, който по някакъв начин е свързан със семейството на Самуел – част от германското протестантско малцинство там. Тук са бабата Карлине, съвременница на крал Михай I и убедена монархистка, запазила завинаги обноските си и вкуса към изяществото на някогашното време; синът ѝ Ханес, пастор, в чиято честност и човечност Секуритате ще забие клин; съпругата му Флорентине – най-независимата и неуловима героиня в романа, която отстоява своето място в периферията на общността; техният син Самуел, крайно мълчалив и саможив младеж, но затова пък превърнал се в магнит за мнозина благодарение на способността си да слуша другия; любимата му Стана, която охранява своята крехка чувствителност под задушливата сянка на строгия си и агресивен баща – функционер на режима, упражняващ психическо насилие над семейството и съселяните си; Оз, приятелят на Самуел, заедно с когото ще извършат крайъгълна дързост; Бене – един от гей студентите от ГДР, които пасторът приютява в къщата си, преди години по-късно той да се върне в съвсем друго амплоа; дъщерята на Самуел – Ливия, която в наши дни ще спои нишките на миналото и вероятно ще зачене бъдещето, преди и то на свой ред да се превърне в история. Защото:

Казват, че животът продължава, а никой не забелязва колко заплашително звучат тези думи. Животът продължава, с него и смъртта…

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

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

Макар първата половина на книгата да е чувствително по-стегната и силна, а към края Волф като че ли леко да поизпуска нишките на тази плътна концентрация, разказът е доказателство, че животът е направен именно от подробностите, от неуловимото, от неясните очертания. За тях може да се каже онова, което героят Ханес мисли:

Да се приютиш в книга, да вкараш решаващ гол, слънцето да ти отреди място в градината – това е времето на мига, времето, което Ханес търсеше, което обичаше повече от онова, редящо часове, дни, седмици, сякаш трябва да води нанякъде.

Да, времето в романа е важно. В началото на втора глава Волф пише:

Има време, което препуска напред, и време, което се връща назад. Време, което се върти в кръг, и време, което не се движи, не е нищо повече от един-единствен миг.

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

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

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

Думите излизаха от устата ѝ случайно, произволно, сякаш живеят собствен живот – рядко постигаше съответствие между онова, което казва и което мисли, нещо естествено за останалите хора

ще заяви най-точните и верни слова, които никой друг няма да посмее да си позволи и които ще предизвикат сблъсъка на семейството ѝ със Секуритате. Принуден да пише протоколни обяснения (доноси), колкото и безобидни и отклоняващи вниманието да са те, Ханес пък ще се радва, че владее няколко езика, така че майчиният му да остане свободен:

Радваше се, че не се налага да използва майчиния си език. Един език му оставаше, незасегнат от забрани и идеологии, един език, на който думите значеха онова, което е казано.

Езиковите особености са равносилни и на идентичността. Културната разлика между източноевропейците и западняците Волф описва съвсем лаконично именно чрез тях – напълно достатъчно, за да можем прекрасно да си представим картината, особено ние:

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

От друга страна, специално внимание изисква самият език на Ирис Волф като автор – една мечтателно-носталгична, ритмична сплав с лекотата на водна боя.

Език ефирен, флуиден, безплътен като вятъра, който не върви по следите на голото сюжетно действие, а скицира „неясните очертания на света“.

Те остават да трептят в съзнанието много след разсейването им, така както трептят жиците след отлитането на вдигнатите от вятъра птици.

По същия икономичен и лаконичен начин, както вече споменах, Волф контурира чрез езика и историко-политическото време. При това тя не драматизира. Дори най-крайъгълните действия са разказани без никаква излишна интензивност, без съспенс, без препятствия – тихо. Вместо да обяснява или да разиграва десетки сцени, тя предава същността на комунизма единствено чрез бягащия от него Оз, чието усещане е, че го преследва огромен зелен дракон. Кратка и ясна метафора.

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

майка му Карлине, чийто живот беше започнал в крайморска вила и приключил на конвейера във фабрика за копчета.

Сънят на Ханес разкрива ясно състоянието на човека под сянката на тоталитаризма – в този свой кошмар героят

въпреки всички усилия на тялото и волята е невъзможно да помръдне или да каже нещо.

Пак така фино е маркирано и съществуването на гей двойки или на многобройните опити за аборти в страната, която уж ги забранява. А най-лаконичното определение за това, че дълго след промените от началото на 90-те, в Източна Европа всичко дълго ще тегне към миналото, е впечатлението на Самуел, когато се връща за първи път, щом това става възможно:

Всичко изглеждаше както винаги. И не беше както винаги.

Самата Ирис Волф, родена през 1977 г., е част от поколението, което дегустира достатъчно от комунизма, за да запомни вкуса му, и в същото време преживява достатъчно рано краха му, за да има време да живее – с много усилия – извън клопката му. Може би затова малко или много се усеща тежнението и симпатията ѝ към героя, който е неин връстник – Самуел. Независимо от времето обаче, „Неясните очертания на света“ в крайна сметка са разказ отвъд него – за силата на връзките, за приятелството, заради което си готов на всичко, за любовта, към която се връщаш. В този разказ вътрешните трептения на човека и свободният вятър на мислите са по-важни от макрокартината, в която той се движи.

Активните дарители на „Тоест“ получават постоянна отстъпка в размер на 20% от коричната цена на всички заглавия от каталога на издателство „Аквариус“, както и на няколко други български издателства в рамките на партньорската програма Читателски клуб „Тоест“. За повече информация прочетете на toest.bg/club.

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

Deploy Amazon QuickSight dashboards to monitor AWS Glue ETL job metrics and set alarms

2023-11-03 Michael Hamilton

Post Syndicated from Michael Hamilton original https://aws.amazon.com/blogs/big-data/deploy-amazon-quicksight-dashboards-to-monitor-aws-glue-etl-job-metrics-and-set-alarms/

No matter the industry or level of maturity within AWS, our customers require better visibility into their AWS Glue usage. Better visibility can lend itself to gains in operational efficiency, informed business decisions, and further transparency into your return on investment (ROI) when using the various features available through AWS Glue.

As your company grows, you should be able to answer simple questions about your AWS Glue usage, such as the following:

Where am I spending the most with AWS Glue?
Where can I save the most by taking advantage of new AWS Glue features?
What does my overall usage look like using AWS Glue?

AWS offers services such as Amazon QuickSight, a serverless business intelligence (BI) service that lets you centralize this view and even ask natural language questions of your data, using Amazon QuickSight Q. QuickSight can give business leaders and their technology counterparts a common landscape for reporting important details of their usage, providing automated narratives to bridge communication gaps.

In this post, we explore how to combine AWS Glue usage information and metrics with centralized reporting and visualization using QuickSight. This can provide you with a more comprehensive view of your usage and tools to help you dive deep into your AWS Glue job run environment. You have metrics available per job run within the AWS Glue console, but they don’t cover all available AWS Glue job metrics, and the visuals aren’t as interactive compared to the QuickSight dashboard.

Although we don’t cover optimizing your jobs for costs in this post, you can refer to Monitor and optimize cost on AWS Glue for Apache Spark to learn how to fine-tune your AWS Glue jobs for performance, efficiency ,and cost-optimization.

Let’s dive in!

Solution overview

The following diagram illustrates the architecture for the given solution. At a high level, a scheduled event triggers an orchestration flow consisting of multiple data, compute, and analytics resources—the output of which culminates as a set of visuals in a BI dashboard.

solution architecture

Now let’s dig into the technical details involved in this solution.

An AWS Step Functions workflow is scheduled to run once per hour through Amazon EventBridge, which triggers an AWS Lambda function that calls the AWS Glue GetJob and GetJobRun APIs. We parse this data to check for jobs that have succeeded, stopped, or failed in the past hour, as well as any streaming jobs. The metadata is extracted from each job run, including information like runtime, start time, end time, auto scaling, number of workers, and worker type, and is written to an Amazon DynamoDB table with TTL (time to live) enabled to ensure the table doesn’t grow too large.

We move into a parallel state to check two tables that Amazon Athena writes the output of the federated queries to. Athena first checks to make sure the tables exist in Amazon Simple Storage Service (Amazon S3), where the data will be stored. If the tables don’t exist, Athena creates them. One federated query gathers AWS Glue metric data from Amazon CloudWatch metrics; the other gathers data from the DynamoDB table where Lambda writes the AWS Glue job metadata it’s collecting. Both federated queries utilize appropriate filtering in order to only scan the necessary data from each source.

There is a choice state for each branch. If there is no new data to be added to a table in Amazon S3, the state ends and waits for the other to complete. For example, there could be an AWS Glue job that is running while the step is evaluating. In this case, the metrics for the job would be inserted in the table on Amazon S3, but the metadata from DynamoDB wouldn’t arrive until the following hour after the job has succeeded, stopped, or failed.

When new metrics or metadata are found, Athena inserts this data to the metrics or metadata tables in Amazon S3, which are both partitioned by the hour. After the data is inserted, the final steps call the QuickSight CreateIngestion API, which triggers data ingestion into QuickSight SPICE to power interactive analysis. At this point, the workflow has finished running and will run again the following hour.

In the following sections, we show you how to set up the solution, explore the dashboards, and configure alarms.

The code for this solution can be found at the AWS samples GitHub repository.

Prerequisites

You should have the following prerequisites:

An AWS account with AWS Identity and Access Management (IAM) privileges sufficient to create the solution resources
QuickSight Standard or Enterprise Edition with a QuickSight user created
An AWS Cloud9 integrated development environment (IDE) or your local machine using your preferred IDE with the following packages installed:
- Node Package Manager (npm)
- Git CLI
- AWS CDK v2
- AWS CDK Library
- TypeScript
The AWS Cloud Development Kit (AWS CDK) bootstrapped in your target AWS account and Region

Deploy solution resources with the AWS CDK

To provision the resources that build the dashboard and keep it up to date, we provide steps to download and deploy the solution via the AWS CDK. The solution was developed with cost-optimization as a priority, but some resources in the stack will incur costs once deployed.

This solution generates the following resources:

IAM role
EventBridge rule
Step Functions state machine
Lambda function
S3 bucket
Two AWS Glue tables and one AWS Glue database
DynamoDB table
Athena queries invoked by Step Functions
QuickSight data source, dataset, analysis, and dashboard

To deploy the solution, complete the following steps:

Clone the source code from AWS samples GitHub repository to the client:
```
git clone https://github.com/aws-samples/glue-metrics-in-quicksight
```

Bootstrap your AWS CDK app:

cd glue-metrics-in-quicksight
npm i aws-cdk-lib
cdk bootstrap

Deploy the solution with the required parameters:
1. The first parameter is for a new S3 bucket to be created, which holds the AWS Glue metrics and metadata.
2. The second parameter is required in order for QuickSight to assign permissions to the user who will manage the assets. Refer to Managing user access inside Amazon QuickSight to find your existing QuickSight users.
```
cdk deploy --parameters BucketName=New-Unique-Bucket-Name --parameters QuicksightUsername=QuickSight-Existing-User
```

If your deployment fails, make sure you installed the AWS CDK library and rerun cdk deploy after installing:

npm i aws-cdk-lib

The deployment may take up to 10 minutes.

After the solution is deployed, the Step Functions state machine will evaluate once per hour if it should ingest data into QuickSight. You can run some AWS Glue jobs after the stack is deployed and check the QuickSight dashboard in the next hour or two, where the job metadata and metrics will be populated for your analysis.

Explore the dashboard

The dashboard contains two sheets: Glue Jobs and Glue Metrics.

The Glue Jobs sheet includes all of the metadata about your AWS Glue job runs, including AWS Glue for Apache Spark, AWS Glue for Ray, and AWS Glue streaming ETL. Most of the visuals also have a hierarchy that you can drill down into with QuickSight, going as low as each specific job run ID. You can use controls to filter by date, job name, and job run ID.

In the following demonstration, you will see the pivot table, which is a simple view of all our job metadata, including estimated cost per job and job run. We open up a job name and see the different job runs. There is one individual job run that we would like to inspect the metrics on, so we choose the job name and choose View metrics for job run id: <my job run id>. This will take us to the Glue Metrics sheet and automatically filter for the job run ID we want to view.

glue information sheet

The Glue Metrics sheet is built to reflect the documentation we provide in AWS Glue resource monitoring. This documentation helps explain each visual in the dashboard. You can use the Glue Metrics sheet to view aggregated metrics across all jobs, a single job, or down to the job run ID.

To populate the Glue Metrics sheet, your AWS Glue jobs must be enabled to capture metrics in CloudWatch.

glue metrics sheet

Set up alerts

Setting up alerts on measures is also straightforward to do in QuickSight. To do so, choose (right-click) one of the tracked measures on either worksheet and choose Create Alarm. This will bring you to the configuration page to set up the metric you’d like to be alerted on.

quicksight alarm

The dashboard is designed to give you the freedom to alter it and make your own visualizations with the metadata and metrics that are provided to you. If you want even more insight into cost, consider deploying the CUDOS dashboard as well!

Clean up

If you no longer need the dashboard, delete the CDK app:

cdk destroy

Conclusion

In this post, we talked about the importance of having observability of your AWS Glue jobs and provided an AWS CDK app that deploys a QuickSight dashboard for you. We hope this helps you optimize your AWS Glue environment using the insights the dashboard provides. To learn about event-based alerting for your AWS Glue for Apache Spark and Ray jobs, refer to Automate alerting and reporting for AWS Glue job resource usage.

About the authors

Michael Hamilton is a Sr Analytics Solutions Architect focusing on helping enterprise customers in the south east modernize and simplify their analytics workloads on AWS. He enjoys mountain biking and spending time with his wife and three children when not working.

Cody Penta is a Solutions Architect at Amazon Web Services and is based out of Charlotte, NC. He has a focus in security and CDK, and enjoys solving the really difficult problems in the technology world. Off the clock, he loves relaxing in the mountains, coding personal projects, and gaming.

Angus Ferguson is a Solutions Architect at AWS who is passionate about meeting customers across the world, helping them solve their technical challenges. Angus specializes in Data & Analytics with a focus on customers in the financial services industry.

First handset with MTE on the market (Project Zero)

2023-11-03 corbet

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

The Google Project Zero blog celebrates
the launch of the Pixel 8 handset, the first to make use of Arm’s
Memory Tagging Extension (MTE). Linux has supported MTE since the 5.10 release in 2020,
but that support has only now shown up (in experimental form) in an
available handset.

I think this is a huge improvement for the general security of the
device – many zero-click attack surfaces involve large amounts of
unsafe C/C++ code, whether that’s WebRTC for calling, or one of the
many media or image file parsing libraries. MTE is not a silver
bullet for memory safety – but the release of the first production
device with the ability to run almost all user-mode applications
with synchronous-MTE is a huge step forward, and something that’s
worth celebrating!

The article includes detailed instructions for how to turn the MTE feature
on.

How to create an AMI hardening pipeline and automate updates to your ECS instance fleet

2023-11-03 Nima Fotouhi

Post Syndicated from Nima Fotouhi original https://aws.amazon.com/blogs/security/how-to-create-an-ami-hardening-pipeline-and-automate-updates-to-your-ecs-instance-fleet/

Amazon Elastic Container Service (Amazon ECS) is a comprehensive managed container orchestrator that simplifies the deployment, maintenance, and scalability of container-based applications. With Amazon ECS, you can deploy your containerized application as a standalone task, or run a task as part of a service in your cluster. The Amazon ECS infrastructure for tasks includes Amazon Elastic Compute Cloud (Amazon EC2) instances in the AWS Cloud, serverless (AWS Fargate) in the AWS Cloud, or on-premises virtual machines (VMs) or servers. You can enable auto-scaling for Amazon ECS capacity providers when using EC2 instances, allowing your infrastructure to dynamically adjust based on workload demands. You define the infrastructure type or the capacity providers where you deploy your tasks or services.

You can choose EC2 instances as the computing resources for your ECS cluster, which allows you to control your cluster’s underlying infrastructure, including the size of EC2 instances, the instance operating system, and extra security controls required by a compliance framework. AWS recommends that you use Amazon ECS-optimized Amazon Machine Images (AMIs), which are set up with the requirements and recommendations to efficiently run your container workloads on Amazon Linux instances. We recommend that you refresh your container instances fleet with the latest ECS-optimized AMIs to include the latest bug fixes and feature updates. However, managing and updating your container instance fleet might become complex as your Amazon ECS workload grows.

In this blog post, I will show you how to create a workflow to enhance Amazon ECS-optimized AMIs by using the CIS Docker Benchmark and automatically updating your EC2 instances in your ECS cluster with the newly created AMIs.

Overview of CIS Docker Benchmark

The CIS Docker Benchmark provides prescriptive guidance for establishing a secure configuration posture for a Docker container engine, container host, container images and build files. The CIS Docker Benchmark has seven sections about Docker and container security:

Host configuration
Docker daemon configuration
Docker daemon configuration files
Container images and build file configuration
Container runtime configuration
Docker security operations
Docker swarm configuration

The solution described in this post covers sections 1, 2, and 3 of the CIS Docker Benchmark, including security recommendations to prepare the host machine used for Amazon ECS workloads, securing the behavior of the Docker daemon (server), and securing Docker-related files and directory permissions and ownerships. However, the solution doesn’t implement all of the controls listed in these three sections. For a complete list of controls implemented, see the solution’s repository.

Solution overview

EC2 Image Builder is a fully managed AWS service, designed to simplify the process of creating, handling, and implementing server images that are custom, secure, and consistently updated. For this solution, you will deploy an EC2 Image Builder pipeline to apply the CIS Docker Benchmarks to an Amazon ECS-optimized AMI and use the created AMI to refresh the Amazon ECS instance fleet. This solution is customizable, so you can select the security controls to harden your base AMI. You can also specify cluster tags during CloudFormation template deployment; these tags will filter the ECS clusters that you have included in the Amazon EC2 instance refresh process. I’ve provided an AWS CloudFormation template that you can use to provision the necessary resources.

Figure 1: Amazon ECS instance refresh workflow

As shown in Figure 1, the solution involves the following steps:

EC2 Image Builder
1. The AMI image pipeline downloads the ansible playbook from the S3 bucket, and runs it against the base image.
2. The pipeline publishes the hardened AMI.
3. The pipeline validates the benchmarks applied to the base image and publishes the results to a test results S3 bucket. It also invokes Amazon Inspector to run a vulnerability scan on the published image.
State machine initiation
1. When the AMI is successfully published, the pipeline publishes a message to the AMI status SNS topic. The SNS topic invokes the State machine initiation Lambda function.
2. The State machine initiation Lambda function extracts the image ID of the published AMI and uses it as the input to initiate the state machine.
State machine
1. The first state gathers information related to Amazon ECS clusters, including the capacity providers for the EC2 auto scaling group. It creates a new launch template version with the hardened AMI image ID for the EC2 auto scaling group.
2. The second state uses the new launch template to initiate an instance refresh for the EC2 auto scaling group.
Instance refresh status update
1. The instance refresh rule selects the auto scaling group instance refresh events (failure, success, and cancellation events) and sends them to the Instance refresh status SNS topic.
2. The Instance refresh status SNS topic sends an email on the instance refresh status to subscribers.
Image update reminder
1. A weekly scheduled rule invokes the Image update reminder Lambda function.
2. The Image update reminder Lambda function retrieves the value for LatestECSOptimizedAMI from the CloudFormation template, and extracts the last modified date of the Amazon ECS-optimized AMI used as the base image in the EC2 Image Builder pipeline. It compares the last modified date of the AMI with the creation date of the latest AMI published by the pipeline. If a new base image is available, it publishes a message to the image update reminder SNS topic.
3. The Image update reminder SNS topic sends a message to subscribers notifying them of a new base image. You need to create a new version of your image recipe to update it with the new AMI.

Prerequisites

To follow along with this walkthrough, make sure that you have the following prerequisites in place:

An AWS account
Permission to create required resources
An existing ECS cluster with one or more EC2 capacity providers
AWS Command Line Interface (AWS CLI) installed
Amazon Inspector for EC2 enabled in your AWS account

Walkthrough

To deploy the solution, complete the following steps.

Step 1: Download or clone the repository

The first step is to download or clone the solution’s repository.

To download the repository

Go to the main page of the repository on GitHub.
Choose Code, and then choose Download ZIP.

To clone the repository

Make sure that you have Git installed.
Run the following command in your terminal:

git clone https://github.com/aws-samples/ecs-image-hardening-and-instance-refresh.git

Step 2: Create an S3 bucket

Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. An S3 bucket is a container for objects stored on Amazon S3. For this walkthrough, you need to create an S3 bucket and copy the content of the ansible folder to your newly created bucket. Make a note of your S3 bucket name because you will need it in the next step.

Step 3: Create the CloudFormation stack

In this step, you deploy the solution’s resources by creating a CloudFormation stack using the provided CloudFormation template. Sign in to your account and choose an AWS Region where you want to create the stack. Make sure that the Region you choose supports the services used by this solution. To create the stack, follow the steps in Creating a stack on the AWS CloudFormation console. Note that you need to provide values for the parameters defined in the template to deploy the stack. The following table lists the parameters that you need to provide.

Parameter	Description
AnsiblePlaybookArguments	ansible-playbook command arguments
AnsiblePlaybookBucket	S3 bucket name containing ansible playbook
CloudFormationUpdaterEventBridgeRuleState	Amazon EventBridge rule that invokes the Lambda function that checks for a new version of the EC2 Image Builder parent image
ClusterTags	Tags in JSON format to filter the ECS clusters that you want to update
ComponentName	Name of the EC2 Image Builder component
DistributionConfigurationName	Name of the EC2 Image Builder distribution configuration
EnableImageScanning	Choose whether or not to enable Amazon Inspector image scanning
ImagePipelineName	Name of the EC2 Image Builder pipeline
InfrastructureConfigurationName	Name of the EC2 Image Builder infrastructure configuration
InstanceType	EC2 Image Builder infrastructure configuration EC2 instance type
LatestECSOptimizedAMI	ECS-optimized AMI parameter name; for more info, see Retrieving Amazon ECS-optimized AMI metadata
libDockerVolumeSize	Container partition size in gigabytes (GB)
libDockerVolumeType	Container partition volume type
RecipeName	Name of the EC2 Image Builder recipe
RootVolumeSize	AMI root partition volume size in GB
RootVolumeType	AMI root partition volume type

Step 4: Set up Amazon SNS topic subscribers

Amazon Simple Notification Service (Amazon SNS) is a web service that coordinates and manages the delivery or sending of messages to subscribing endpoints or clients. An Amazon SNS topic is a logical access point that acts as a communication channel.

The solution in this post creates three Amazon SNS topics to keep you informed of each step of the process. The following is a list of the topics that the solution creates and their purpose.

AMI status topic – a message is published to this topic upon successful creation of an AMI.
Image update reminder topic – a message is published to this topic if a newer version of the base Amazon ECS-optimized AMI is published by AWS.
Instance refresh status topic – a message is published to this topic each time that an ECS cluster capacity provider gets an instance fleet refresh.

You need to manually modify the subscriptions for each topic to receive messages published to that topic.

To modify the subscriptions for the topics created by the CloudFormation template

Sign in to the Amazon SNS console.
In the left navigation pane, choose Subscriptions.
On the Subscriptions page, choose Create subscription.
On the Create subscription page, in the Details section, do the following:
- For Topic ARN, choose the Amazon Resource Name (ARN) of one of the topics that the CloudFormation topic created.
- For Protocol, choose Email.
- For Endpoint, enter the endpoint value. In our example, this is an email address, such as the email address of a distribution list.
- Choose Create subscription.
Repeat the preceding steps for the other two topics.

Step 5: Run the pipeline

The EC2 Image Builder pipeline that the solution creates consists of an image recipe with one component, an infrastructure configuration, and a distribution configuration. I’ve set up the image recipe to create an AMI, select a base image, choose components, and define block device mapping. There’s only one component where building and testing steps are defined. For the building step, the solution creates a separate partition for /var/lib/docker and mounts it to a dedicated device specified in the image recipe. It then applies the CIS Docker Benchmark ansible playbook and cleans up the unnecessary files and folders. In the test step, the solution runs Amazon inspector, a continuous assessment service that scans your AWS workloads for software vulnerabilities and unintended network exposure, and Docker Bench for Security. Optionally, you can create your own components and associate them with the image recipe to make further modifications on the base image.

You will need to manually run the pipeline by using either the AWS Management Console or AWC CLI.

To run the pipeline (console)

Open the EC2 Image Builder console.
From the pipeline details page, choose the name of your pipeline.
From the Actions menu at the top of the page, select Run pipeline.

To run the pipeline (AWS CLI)

Make sure that you have properly configured your AWS CLI.
Run the following command. Replace <pipeline region> with your own information.

aws imagebuilder list-image-pipelines –region <pipeline region>

From the list of pipelines, find the pipeline named ECSAnsiblePipeline and note the pipeline ARN, which you will use in the next step.
Run the pipeline. Make sure to replace <pipeline arn> and <region> with your own information.

aws imagebuilder start-image-pipeline-execution –image-pipeline-arn <pipeline arn> –region <region>

The following is a process overview of the image hardening and instance refresh:

Image hardening – when you start the pipeline, EC2 Image Builder creates the required infrastructure to build your AMI, applies the ansible playbook (CIS Docker Benchmark) to the base AMI, and publishes the hardened AMI. A message is published to the AMI status topic as well.
Image testing – after publishing the AMI, EC2 Image Builder scans the newly created AMI with Amazon Inspector and reports the findings back. It also runs Docker Bench for Security to verify the changes that the ansible playbook made to the base AMI and publishes the results to an S3 bucket.
State machine initiation – after a new AMI is successfully published, the AMI status topic invokes the State machine initiation Lambda function. The Lambda function invokes the instance refresh state machine and passes on the AMI info.
Instance refresh – the instance refresh state machine has two steps:
1. Gather cluster information – a Lambda function gathers information regarding EC2 capacity providers and their associated auto scaling groups. For each auto scaling group, it creates a new launch template and includes the hardened AMI information. When you create the CloudFormation stack, if you pass a tag or a list of tags, only clusters with matching tags are processed in this step.
2. Auto scaling group instance refresh – the state machine uses the output of the first Lambda function (first state) and starts instance refresh for auto scaling groups in parallel (second state). An EventBridge rule publishes a message to the Instance refresh status topic upon successful refresh of each auto scaling group.

This solution also creates an EventBridge rule that is invoked weekly. This rule invokes the Image update reminder Lambda function, and notifies you if a new version of your base AMI has been published by AWS so that you can run the pipeline and update your hardened AMI.

Conclusion

In this blog post, you learned how to create a workflow to harden Amazon ECS-optimized AMIs by using the CIS Docker Benchmark and to automate the refresh of EC2 instances in your ECS clusters. This automated workflow has several advantages. First, it helps ensure a consistent and standardized process for image hardening, reducing potential human errors and inconsistencies. By automating the entire process, you can apply security and compliance standards across your instances. Second, the tight integration with AWS Step Functions enables smooth, orchestrated updates to the ECS cluster instances, enhancing the reliability and predictability of deployments. This automation also reduces manual intervention, helping you achieve time savings so that your teams can focus on more value-driven tasks. Moreover, this systematic approach helps to enhance the security posture of your Amazon ECS workloads because you can address vulnerabilities rapidly and systematically, helping to keep the environment resilient against potential threats.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Всеки има право на образование

2023-11-03 Мирела Петкова

Post Syndicated from Мирела Петкова original https://www.toest.bg/vseki-ima-pravo-na-obrazovanie/

Всеки има право на образование

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

Свободно падане

Кой е отговорен, когато едно дете отпада от образователната система на 14 години? Най-лесното е да кажем, че семейството не смята образованието за ценност и няма интерес към него. Но това би значило, че виждаме децата и тяхното благополучие само като отговорност на родителите, а не като обществена отговорност. Пламена Николова е част от екипа на Националната мрежа за децата (НМД), където от години отговаря за формирането на приоритети в политиките за деца и активното застъпничество пред институциите. Според нея отпадането от училище не е само семеен или само обществен проблем, а по-скоро стои някъде по средата, защото интересът какви ще са бъдещите граждани на тази страна, е общ.

От 2018 г. у нас съществува Механизъм за междуинституционално сътрудничество, който се опитва да проследи какво става с отпадащите от училище деца. Макар в механизма да участват ключовите институции, работещи с деца – образователни, социални, здравни и общински власти, Пламена е категорична, че продължава да има проблем с установяването на това колко, как, къде и защо деца отпадат от училище.

Отваряме една голяма скоба – отпадането е проблем, засягащ не само младите майки.

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

Както отбелязахме в предишните части на поредицата, данни, които да ни дадат нюанс каква част от хилядите отпаднали са напуснали класната стая поради забременяване, няма.

Как се връща едно момиче в училище?

Един донякъде невидим източник на подкрепа за младите майки и техните бебета са социалните услуги и работници из цялата страна. „Тоест“ разговаря с Надежда Стойчева, социална работничка в комплекс за социални услуги за деца и семейства към русенското сдружение „Еквилибриум“, и Савина Митрашкова, също социална работничка, работеща в звено „Майка и бебе“ в Пловдив.

Главната цел на подобни структури е да се помогне на жени в риск да се справят и да не изоставят бебетата си. Освен с продукти за бебето, помощ при отглеждането му и осигуряване на подслон при нужда, подобни социални услуги съдействат на младите майки с кандидатстване за социални помощи и търсене на общинско жилище. Дори по-важно, помагат на момичетата да продължат образованието си или да си потърсят работа.

Що се отнася до връщането в училище, Надежда разказва, че тя и колегите ѝ посещават всяко училище, за да проведат срещи с директори и заместник-директори и да бъдат в помощ на младите жени, като ги информират за изискванията, които трябва да покрият.

Една от пречките, с които се срещат при записването, са сроковете. Редовната форма е често непосилна, защото майката трябва да полага грижи за детето си, но записването задочно е възможно само през септември, 20 дни преди началото на изпитната сесия. Надежда разказва, че дори младата майка да се чувства подкрепена, често мотивацията ѝ не е огромна и ако е говорено с нея през март, а училището не може да я приеме тогава, тя трябва да чака до септември, което често е силно обезкуражаващо. Надежда споделя и че „някои училища се плашат от бюрокрацията и бумащината, защото, ако тя отново спре да ходи на училище, трябва да я търсят и да се опитват да я връщат, и като цяло нямат доверие към нея“. Въпреки това опитът ѝ е, че повечето училища работят усилено да върнат децата в клас.

Друга значителна спънка са малките населени места. „Имаше желание от няколко млади майки да се върнат, но училищата са малки и не разполагат с достатъчно учители. Съответно нямат задочна форма на обучение и въпреки желанието на директорите е невъзможно.“ Иначе казано, ако една жена, прекъснала училище, пожелае да се върне към образованието, тя трябва да се запише в големия град. Това обаче често е невъзможно заради грижи за бебето, липса на финанси или липса на подкрепа от роднините, които не искат да я оставят да пътува далече сама.

Савина Митрашкова подчертава, че освен медиацията с училища, психологическата помощ също е изключително важна. „Голямо значение има нагласата на обществото към тези момичета. Приемаме ли, че на 15 години са станали майки, или по-скоро ги гледаме с критика? Според мен е второто. Общата нагласа е, че се гледа с обвинение към момичето, забременяло в ранна възраст. Няма разбиране и липсва подкрепа от обществото. А пък в училищата имаме представители на цялото общество и си представям какво е, без да броим частните случаи на учители, които се борят за тези деца“, разказва Савина. Тоест когато говорим за невъзможност за връщане в класната стая, в тежест са не само бюрократичните процеси – отношението от заобикалящите и нивото на подкрепа са не по-малко важни.

Според Савина не става въпрос единствено за ефектите от раждането и отглеждането на бебето, а за сложен процес, който започва от ранното детство и засяга начина, по който пораства едно момиче. За да няма желание да се върне в училище, това е свързано и с ниска самооценка и липса на самоувереност. „В моята практика ми се е случвало момиче да желае да изкара шофьорски курс, но да няма нужната степен на образование, за да го направи. Толкова ѝ е ниска самооценката, че не вярва, че може завърши дадения клас и да изкара курса.“ Звено „Майка и бебе“ в Пловдив работи усилено именно в посока тези момичета да бъдат подкрепени и насърчени да вярват в себе си.

Сегрегация по български

Но въпросът не е само дали можеш да се запишеш в училище, а в какво училище ще учиш. По данни от проучване от 2020 г., представено от център „Амалипе“, водещата ромска организация у нас, над 330 училища в България са сегрегирани. Това включва както общообразователни училища, така и професионални гимназии.

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

Говорейки си за сегрегация, трябва да подчертаем важността на местната власт за образователните институции. „Изключително важно е Общината да развива истински политики за образование по десегрегация. Не може МОН да отиде например в Добрич и да каже как да не си сегрегират училищата“, смята Пламена Николова от НМД. Кремена Георгиева, педагогическа съветничка в Професионалната гимназия по текстил и облекло „Добри Желязков“ в Сливен, също подчертава ролята на различните местни институции отвъд училището. Кремена разказва, че макар да има наложени глоби, не е изключение от правилото те да са в резултат на лична преценка, защото една глоба е антиреклама за местната власт в малките населени места.

Като успешен пример за десегрегация „Амалипе“ и НМД дават Габрово. Макар ромското население там да е сравнително малко, също е имало „ромско“ училище. Чрез обединени усилия на Общината, Регионалното управление на образованието и център „Амалипе“ училището е затворено, а учениците са преразпределени към други училища. Осигурен е транспорт за децата, за които е проблем да посещават различни образователни институции поради отдалечеността си от тях.

Женската действителност

Една от основните тези в предишните части на поредицата беше, че ранната бременност не е етнически феномен. Тогава защо си говорим за образователната сегрегация на ромите в България? Защото тя е сред факторите, които правят ромската жена в пъти по-уязвима от отпадане от образователната система в сравнение с една етническа българка. Всичко това се утежнява от предразсъдъците в самата ромска общност, от бедността и чувството за безнадеждност.

Макар хората, с които говори „Тоест“, да посочват, че в повечето случаи на ранна бременност става въпрос за момичета от ромски произход, тук отново обръщаме внимание, че страната ни продължава да е първенец в ЕС по аборти и че всяка трета бременност у нас завършва с аборт. Абортът и ранното раждане са част от един конкретен проблем – липсата на сексуално и здравно образование и култура. И този проблем засяга всички, но има различни проявления.

Базирайки се на опита си в Русе, Надежда добавя, че не може да се каже, че само в ромската общност има тийнейджърки, които не знаят как да се предпазват от забременяване. „Все още в много семейства сексуалната култура е табу. Забелязваме го и в български семейства, но просто не до такава степен както в ромските“, допълва тя. Ако в ромската общност не е прието да се направи аборт и затова момичетата раждат, то етническите българки, които забременяват като тийнейджърки, в повечето случаи правят аборт и продължават живота си, доколкото е възможно.

Важен фактор, свързан с културните особености, е стойността на образованието като ценност за женската действителност в ромската общност. Или иначе казано, каква е ролята на мъжа и жената в общността. Надежда дава пример с това, че продължаването на образованието на момчетата е насърчавано често дори само поради факта, че за изкарването на шофьорска книжка е нужен завършен Х клас. Подобни са схващанията и на други места в страната. „Жената не може да е независима, тя трябва да бъде зависима от мъжа, той е този, който кара кола, ходи на работа и изкарва пари“, казва Савина Митрашкова за разбиранията в ромската общност. Би било невъзможно да си говорим за образованието на едно момиче и пречките пред него, без да се отбележат и тъкмо тези патриархални виждания, които ограничават образователните възможности на младите жени в България.

Загубеното доверие

Социалните услуги са единствената опора за момичетата, които нямат подкрепа от възрастните в семейството, от общността или от училището. Но както знаем, социалната дейност е в незавидно положение по отношение на човешкия ресурс и на обезпечаването на самите работници. Наблюденията на Пламена Николова сочат, че има цели общини в България, в които един социален работник отговаря за 60 до 90 случая. Това практически означава следното: извършването на същинска социална работа, при която се проследява и подкрепя едно семейство, е невъзможно.

Личният пример е най-ценният инструмент за връщането на едно момиче в училище, смятат всички експерти, с които разговаряхме. Срещите с неформални лидери от общностите в по-малките населени места, с лекари, пастори, хора, осигуряващи сезонна работа, са важни, защото такива личности успяват да достигнат с посланията си до децата. Също и публични фигури. Кремена си спомня скорошното гостуване на певицата Роксана в училището, в което работи, и нейния разказ за житейския ѝ път и трудностите, през които е преминала като майка тийнейджърка. При всички положения разговорът с човек с подобен на твоя произход, но постигнал нещо, на което се възхищаваш, е многократно по-полезен от безпредметното размахване на пръст от обществото.

В училището в Сливен, където работи Кремена, децата са между 350 и 380, като по нейни думи има не повече от десетина ученици, които не са от ромски или турски произход. В този случай съвместните дейности с „Амалипе“ също са източник на вдъхновение за децата, защото, посещавайки събития на центъра из страната, те виждат успели хора от своите общности и имат основание да вярват, че също биха могли да постигнат успех, ако учат.

„Смятам, че за превенция на ранните бракове е по-важно да се работи с родителите, отколкото с децата“, категорична е Кремена. Ако родителите решат да спрат бременната си или току-що родила дъщеря от училище, нещата, които един педагогически съветник като Кремена може да направи, са малко.

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

Когато привличаме родителите като партньори, всъщност повишаваме доверието. Наясно сме, че екипът на училището пръв трябва да подаде ръка на родителите и да ги приобщи, защото без тях няма как да се справим, колкото и да работим с децата.

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

Решението не се изчерпва с прехвърляне на цялата тежест върху училищата, защото те нямат инструментите да върнат децата в час. „Когато родителят не желае да осигури присъствието на детето си в училище, каквито и мерки да измисли всяко училище, те няма да проработят. Пишем писма до „Закрила на детето“ или до кметовете, когато видим, че някое дете много отсъства, търсим съдействие от различни институции, чиито представители могат да се срещнат и да поговорят с родителите, за да опитат по някакъв начин да им въздействат“, разказва Кремена Георгиева.

Думите на Пламена Николова от НМД допълват това. Според нея истинската превенция на отпадането от образованието е пресечна точка между социалната и образователната работа. Училището може да извърви пътя донякъде, но в същото време и то трябва да бъде подкрепено от социалната система за закрила, ако има насилие или бедност в семейството, които да възпрепятстват една млада жена да учи.

Въпреки всички пробойни в системата Кремена е категорична, че с много бавни стъпки нещата се променят. Тя работи в Професионалната гимназия по текстил и облекло „Добри Желязков“ от 21 години и разказва, че допреди 10 години не е имало момичета от определени населени места със завършен 12 клас. Днес това вече не е така. Като на шега добавя, че и самите педагогически съветници и учителският колектив се учат в движение, защото няма училище за работата, която вършат. „Ние се борим за всяко дете, защото знаем, че всяко дете е човешка съдба и всеки има право на образование“, завършва тя.

OpenELA’s first code drop

2023-11-03 corbet

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

The Open Enterprise Linux Association, a
joint venture founded by CIQ, Oracle, and SUSE, has announced
its first code release.

OpenELA is excited to announce that the source code for all
packages necessary for anyone to build a derivative Enterprise
Linux operating system is now available. The initial focus is on
EL8 and EL9, and packages for EL7 are forthcoming. The project is
committed to ensuring the continued availability of EL sources to
the community indefinitely.

The organization has also announced a technical
steering committee made up of “highly experienced individuals from
the founding companies“.