Open-source News

1. Wii U emulator Cemu 2.0 out, goes open source and gets Linux support  GamingOnLinux
2. How to Install Ubuntu on Windows Services for Linux  ITPro Today
3. Getting Started With Windows Subsystem for Linux  Dignited
4. Cemu Emulator For The Wii U Now Open-Source, Building On Linux  Phoronix
5. Here's why Wii U emulator Cemu going open source is a big deal for emulation—and for the Steam Deck  PC Gamer
6. View Full Coverage on Google News

Wii U emulator Cemu 2.0 out, goes open source and gets Linux support  GamingOnLinux

Linux-First AI Image Upscaler Upscayl Released its First Version  It's FOSS News

Cemu is a popular emulator for the Nintendo Wii U that can successfully run many games as well as homebrew titles. Cemu started off with just Windows support but then at the beginning of the year laid out plans to go open-source and provide Linux support. They've pulled that off and the code is now out there in a public GitHub repository...

The current Intel open-source "ANV" Vulkan driver within Mesa supports graphics hardware going back to the "Gen7" graphics found with Haswell. However, Intel open-source Linux graphics driver engineers are preparing to separate the old Haswell (Gen7) and Broadwell (Gen8) graphics into a separate Mesa driver so they can better focus on improving their modern Vulkan driver that would then be limited to Skylake Gen9 graphics and newer...

The X.Org project "xisxwayland" is out with a new version of this simple program that can be easily called by shell scripts and other simple uses for checking to see whether the running X.Org Server is a genuine X11 server or more commonly these days an XWayland server running within a Wayland environment...

For speeding up the actual Mesa continuous integration (CI) process itself with frequently building new revisions of Mesa3D, their CI infrastructure is beginning to make use of the Mold linker as a high performance alternative to the GNU Gold and LLVM LLD linkers. This is yielding a "substantial" performance improvement in tests for being able to turnaround CI jobs faster and in turn allowing Mesa developers to be more efficient...

Games publisher PQube accused of 'predatory practices' and being manipulative  GamingOnLinux

Open-source firmware consulting firm 3mdeb last year worked on Fwupd support for FreeBSD so system firmware updates can be more easily handled on that popular BSD operating system and leveraging the Fwupd/LVFS infrastructure that's been happening for years in the Linux space. Their most recent target is now DragonFlyBSD for handling of UEFI firmware updates with Fwupd...

One of the great things about Jason Ekstrand having joined Collabora at the start of the year is that the former Intel graphics engineer, who was on the team that created their original Vulkan driver, can now work on whatever open-source driver code he wishes. Among other upstream Mesa work, he's recently been contributing to the new "NVK" NVIDIA Vulkan driver and also the RADV driver too...

7 sudo myths debunked Peter Czanik Wed, 08/24/2022 - 03:00 Register or Login to like Register or Login to like

Whether attending conferences or reading blogs, I often hear several misconceptions about sudo. Most of these misconceptions focus on security, flexibility, and central management. In this article, I will debunk some of these myths.

Many misconceptions likely arise because users know only the basic functionality of sudo. The sudoers file, by default, has only two rules: The root user, and members of the administrative wheel group, can do practically anything using sudo. There are barely any limits, and optional features are not enabled at all. Even this setup is better than sharing the root password, as you can usually follow who did what on your systems using the logs. However, learning some of the lesser-known old and new features gives you much more control and visibility on your systems.

If you only know how to give access in sudo to a specific command for a specific user or group, I would recommend reading some of my earlier articles on sudo:

• What you probably didn't know about sudo
• 5 new sudo features sysadmins need to know in 2022

As these article titles suggest, many beneficial possibilities have been available for over a decade without users noticing or using them, and sudo is still continuously developed. My responses to these common misconceptions may teach you about some new features!

More Linux resources Linux commands cheat sheet Advanced Linux commands cheat sheet Free online course: RHEL technical overview Linux networking cheat sheet SELinux cheat sheet Linux common commands cheat sheet What are Linux containers? Our latest Linux articles Sudo configuration is stored locally, making it vulnerable

Yes, by default, configuration is stored locally. If you give users root shell or editor access, they can modify the sudoers file. On a single host, there is nothing you can do about it. Once you have multiple hosts, however, there are many ways to solve this problem.

All major configuration management platforms, including Ansible, have support to maintain the sudoers file. Even if the actual configuration is a local file, it is maintained from a central location. Any local changes can be detected, reported, and changed back automatically to the centrally managed version.

Another possibility is using LDAP (lightweight directory access protocol) to store sudo's configuration. It has quite a few limitations—for example, you cannot use aliases—but using LDAP means that the configuration is stored in a central directory, any change is effective immediately, and the local user cannot modify the settings.

Using LDAP for central configuration is difficult

If you have just a couple of freshly installed hosts, getting started with LDAP to store the sudo configuration can be difficult. However, most organizations, even with just a few hosts, already have LDAP or Active Directory (AD) running and personnel who know how to configure and maintain these directory services. Adding sudo support to an already existing directory service is not prohibitively difficult. It is even possible to have both local sudoers and LDAP sudoers, and to specify the order of evaluation, for example, LDAP first, then local, or local first, then LDAP.

Maintaining a sudoers file on multiple hosts is error prone and a compliance problem

Yes, this is right, as long as you edit individual sudoers files by hand. However, as suggested in my response to the previous myth, even with a very low host count, most organizations introduce some kind of directory services, such as LDAP or AD, and configuration management. You can use a directory service to store the sudo configuration centrally, or you can use Ansible and other configuration management applications to maintain the sudoers files on your hosts from a central configuration repository.

The sudo codebase is too large

Yes, it is large. Some even call it a Death Star and say that a large codebase also means that it is insecure. There are smaller software projects; however, those implement only a very basic subset of sudo functionality. Using those, you lose a lot of visibility into what is happening on your systems (just think about session recording). Commercial sudo replacements might implement many sudo features. However, sudo is open source and one of the most analyzed open source codes. Commercial codebases are even larger—and not analyzed by third parties.

Shell access visibility is tricky

Using just the default settings, shell or editor access makes it hard to see what's happening inside a shell session. However, session recordings have been able to make visible what happened inside a shell session for well over a decade. Version 1.9.0 of sudo introduced a central collection of session recordings, so they could not be deleted or modified by the local user. Version 1.9.8 also includes subcommand logging. You can use the logs to check any commands executed in a sudo session and only watch recordings when necessary (for example, if a user starts Midnight Commander). Watching session recordings is tedious and can be very time consuming—some people even have three-day-long sudo sessions—so reviewing logs whenever possible is definitely preferable.

You can't use two-factor authentication in sudo

That is right: There is no out-of-the-box two-factor authentication (2FA) in sudo. However, you can implement 2FA using Linux PAM. Or, if you prefer, you can do it inside sudo. Sudo has a modular architecture and thus can be extended. Version 1.9 of sudo introduced the approval plugin API (application programming interface), making it possible to have additional restrictions before executing a command. You can code your approval plugin in either C or Python and implement 2FA yourself.

More for sysadmins Enable Sysadmin blog The Automated Enterprise: A guide to managing IT with automation eBook: Ansible automation for Sysadmins Tales from the field: A system administrator's guide to IT automation eBook: A guide to Kubernetes for SREs and sysadmins Latest sysadmin articles Sudo logs do not improve security

If you collect log messages only locally and you do not check them at all, then log messages do not improve security. However, even syslogd, the original syslog implementation from more than three decades ago, supported central log collection. Removing sudo logs from a remote host or a cloud service is not as easy as modifying local logs.

There is also built-in support for central logging in sudo. Using sudo_logsrvd you can collect not only session recordings but event logs as well. In the end, sudo_logsrvd can forward events to syslog (default) or maintain its own log files.

Any questions?

I hope my article helped to resolve some of the myths surrounding sudo. If you have any sudo questions, do not hesitate to reach out to the sudo users mailing list.

The most common misconceptions I've come across involve security, flexibility, and central management. Here, I debunk these sudo myths.

Image by:

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

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

Your guide to DistSQL's cluster governance capability Raigor Jiang Wed, 08/24/2022 - 03:00 1 reader likes this 1 reader likes this

Apache ShardingSphere 5.0.0-Beta version with DistSQL made the project even more beloved by developers and ops teams for its advantages, such as dynamic effects, no restart, and elegant syntax close to standard SQL. With upgrades to 5.0.0 and 5.1.0, the ShardingSphere community has once again added abundant syntax to DistSQL, bringing more practical features.

In this article, the community co-authors will share the latest functions of DistSQL from the perspective of cluster governance.

ShardingSphere clusters

In a typical cluster composed of ShardingSphere-Proxy, there are multiple compute nodes and storage nodes, as shown in the figure below.

Image by:

(Jiang Longtao and Lan Chengxiang, CC BY-SA 4.0)

To make it easier to understand, in ShardingSphere, we refer to proxy as a compute node and proxy-managed distributed database resources (such as ds_0 or ds_1) as resources or storage nodes.

Multiple proxy or compute nodes are connected to the same register center. They share configuration and rules, and they can sense each other's online status. These compute nodes also share the underlying storage nodes, so they can perform read and write operations to the storage nodes at the same time. The user application is connected to any compute node and can perform equivalent operations.

Through this cluster architecture, you can quickly scale proxy horizontally when compute resources are insufficient, reducing the risk of a single point of failure and improving system availability. The load-balancing mechanism can also be added between the application and compute node.

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

Compute node governance is suitable for cluster mode. For more information about the ShardingSphere modes, please see Your detailed guide to Apache ShardingSphere's operating modes.

Cluster preparation

Take a standalone simulation of three proxy compute nodes as an example. To use the mode, follow the configuration below:

mode:
type: Cluster
repository:
type: ZooKeeper
props:
namespace: governance_ds
server-lists: localhost:2181
retryIntervalMilliseconds: 500
timeToLiveSeconds: 60
maxRetries: 3
operationTimeoutMilliseconds: 500
overwrite: false

Execute the bootup command separately:

sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3307
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3308
sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3309

After the three proxy instances are successfully started, the compute node cluster is ready.

SHOW INSTANCE LIST

Use the client to connect to any compute node, such as 3307:

mysql -h 127.0.0.1 -P 3307 -u root -p

View the list of instances using SHOW INSTANCE LIST:

mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+---------+
| instance_id    | host      | port | STATUS  |
+----------------+-----------+------+---------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled |
| 10.7.5.35@3308 | 10.7.5.35 | 3308 | enabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled |
+----------------+-----------+------+---------+

The above fields mean:

• instance_id: The id of the instance, which is currently composed of host and port
• host: Host address
• port: Port number
• status: The status of the instance, either enabled or disabled

DISABLE INSTANCE

Use a DISABLE INSTANCE statement to set the specified compute node to a disabled state. The statement does not terminate the process of the target instance but only virtually deactivates it.

DISABLE INSTANCE supports the following syntax forms:

DISABLE INSTANCE 10.7.5.35@3308;
#or
DISABLE INSTANCE IP=10.7.5.35, PORT=3308;

For example:

mysql> DISABLE INSTANCE 10.7.5.35@3308;
Query OK, 0 ROWS affected (0.02 sec)
mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+
| instance_id    | host      | port | STATUS   |
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled  |
| 10.7.5.35@3308 | 10.7.5.35 | 3308 | disabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled  |
+----------------+-----------+------+----------+

After executing the DISABLE INSTANCE statement by querying again, you can see that the instance status of Port 3308 has been updated to disabled, indicating that the compute node has been disabled.

If there is a client connected to 10.7.5.35@3308, executing any SQL statement will prompt an exception:

1000 - Circuit break mode IS ON.

You are not allowed to disable the current compute node. If you send 10.7.5.35@3309 to DISABLE INSTANCE 10.7.5.35@3309, you will receive an exception prompt.

ENABLE INSTANCE

Use an ENABLE INSTANCE statement to set the specified compute node to an enabled state. ENABLE INSTANCE supports the following syntax forms:

ENABLE INSTANCE 10.7.5.35@3308;
#or
ENABLE INSTANCE IP=10.7.5.35, PORT=3308;

For example:

mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+
| instance_id    | host      | port | STATUS   |
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled  |
| 10.7.5.35@3308 | 10.7.5.35 | 3308 | disabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled  |
+----------------+-----------+------+----------+
mysql> ENABLE INSTANCE 10.7.5.35@3308;
Query OK, 0 ROWS affected (0.01 sec)
mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+
| instance_id    | host      | port | STATUS   |
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled  |
| 10.7.5.35@3308 | 10.7.5.35 | 3308 | enabled  |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled  |
+----------------+-----------+------+----------+

After executing the ENABLE INSTANCE statement, you can query again and view that the instance state of Port 3308 has been restored to enabled.

How to manage compute node parameters

In our article Integrating SCTL into DISTSQL's RAL: Making Apache ShardingSphere perfect for database management, we explained the evolution of ShardingSphere control language (SCTL) to resource and rule administration language (RAL) and the new SHOW VARIABLE and SET VARIABLE syntax.

However, in 5.0.0-Beta, the VARIABLE category of DistSQL RAL only contained only the following three statements:

SET VARIABLE TRANSACTION_TYPE = xx; （LOCAL, XA, BASE）
SHOW VARIABLE TRANSACTION_TYPE;
SHOW VARIABLE CACHED_CONNECTIONS;

By listening to the community's feedback, we noticed that querying and modifying the props configuration of proxy (located in server.yaml) is also a frequent operation. Therefore, we have added support for props configuration in DistSQL RAL since the 5.0.0 GA version.

SHOW VARIABLE

First, we'll review how to configure props:

props:
max-connections-size-per-query: 1

kernel-executor-size: 16  # Infinite by default.

proxy-frontend-flush-threshold: 128  # The default value is 128.

proxy-opentracing-enabled: false

proxy-hint-enabled: false

sql-show: false

check-table-metadata-enabled: false

show-process-list-enabled: false

# Proxy backend query fetch size. A larger value may increase the memory usage of ShardingSphere Proxy.

# The default value is -1, which means set the minimum value for different JDBC drivers.

proxy-backend-query-fetch-size: -1

check-duplicate-table-enabled: false

proxy-frontend-executor-size: 0 # Proxy frontend executor size. The default value is 0, which means let Netty decide.

# Available options of proxy backend executor suitable: OLAP(default), OLTP. The OLTP option may reduce time cost of writing packets to client, but it may increase the latency of SQL execution

# and block other clients if client connections are more than `proxy-frontend-executor-size`, especially executing slow SQL.

proxy-backend-executor-suitable: OLAP

proxy-frontend-max-connections: 0 # Less than or equal to 0 means no limitation.

sql-federation-enabled: false

# Available proxy backend driver type: JDBC (default), ExperimentalVertx

proxy-backend-driver-type: JDBC

Now, you can perform interactive queries by using the following syntax:

SHOW VARIABLE PROXY_PROPERTY_NAME;

For example:

mysql> SHOW VARIABLE MAX_CONNECTIONS_SIZE_PER_QUERY;
+--------------------------------+
| max_connections_size_per_query |
+--------------------------------+
| 1                              |
+--------------------------------+
1 ROW IN SET (0.00 sec)
mysql> SHOW VARIABLE SQL_SHOW;
+----------+
| sql_show |
+----------+
| FALSE    |
+----------+
1 ROW IN SET (0.00 sec)
……

Note: For DistSQL syntax, parameter keys are separated by underscores.

SHOW ALL VARIABLES

Since there are plenty of parameters in proxy, you can also query all parameter values through SHOW ALL VARIABLES:

mysql> SHOW ALL VARIABLES;
+---------------------------------------+----------------+
| variable_name                         | variable_value |
+---------------------------------------+----------------+
| sql_show                              | FALSE          |
| sql_simple                            | FALSE          |
| kernel_executor_size                  | 0              |
| max_connections_size_per_query        | 1              |
| check_table_metadata_enabled          | FALSE          |
| proxy_frontend_database_protocol_type |                |
| proxy_frontend_flush_threshold        | 128            |
| proxy_opentracing_enabled             | FALSE          |
| proxy_hint_enabled                    | FALSE          |
| show_process_list_enabled             | FALSE          |
| lock_wait_timeout_milliseconds        | 50000          |
| proxy_backend_query_fetch_size        | -1             |
| check_duplicate_table_enabled         | FALSE          |
| proxy_frontend_executor_size          | 0              |
| proxy_backend_executor_suitable       | OLAP           |
| proxy_frontend_max_connections        | 0              |
| sql_federation_enabled                | FALSE          |
| proxy_backend_driver_type             | JDBC           |
| agent_plugins_enabled                 | FALSE          |
| cached_connections                    | 0              |
| transaction_type                      | LOCAL          |
+---------------------------------------+----------------+
21 ROWS IN SET (0.01 sec)SET VARIABLE

Dynamic management of resources and rules is a special advantage of DistSQL. Now you can also dynamically update props parameters by using the SET VARIABLE statement. For example:

#Enable SQL log output
SET VARIABLE SQL_SHOW = true;
#Turn on hint function
SET VARIABLE PROXY_HINT_ENABLED = true;
#Open federal query
SET VARIABLE SQL_FEDERATION_ENABLED = true;
……

The SET VARIABLE statement can modify the following parameters, but the new value takes effect only after the proxy restart:

• kernel_executor_size
• proxy_frontend_executor_size
• proxy_backend_driver_type

The following parameters are read-only and cannot be modified:

• cached_connections

Other parameters will take effect immediately after modification.

How to manage storage nodes

In ShardingSphere, storage nodes are not directly bound to compute nodes. One storage node may play different roles in different schemas at the same time, in order to implement different business logic. Storage nodes are always associated with a schema.

For DistSQL, storage nodes are managed through RESOURCE-related statements, including:

• ADD RESOURCE
• ALTER RESOURCE
• DROP RESOURCE
• SHOW SCHEMA RESOURCES

Schema preparation

RESOURCE-related statements only work on schemas, so before operating, you need to create and use the USE command to successfully select a schema:

DROP DATABASE IF EXISTS sharding_db;
CREATE DATABASE sharding_db;
USE sharding_db;ADD RESOURCE

ADD RESOURCE supports the following syntax forms:

• Specify HOST, PORT, DB

ADD RESOURCE resource_0 (
HOST=127.0.0.1,
PORT=3306,
DB=db0,
USER=root,
PASSWORD=root
);

• Specify URL

ADD RESOURCE resource_1 (
URL="jdbc:mysql://127.0.0.1:3306/db1?serverTimezone=UTC&useSSL=false",
USER=root,
PASSWORD=root
);

The above two syntax forms support the extension parameter PROPERTIES, which is used to specify the attribute configuration of the connection pool between the proxy and the storage node.

For example:

ADD RESOURCE resource_2 (
HOST=127.0.0.1,
PORT=3306,
DB=db2,
USER=root,
PASSWORD=root,
PROPERTIES("maximumPoolSize"=10)
),resource_3 (
URL="jdbc:mysql://127.0.0.1:3306/db3?serverTimezone=UTC&useSSL=false",
USER=root,
PASSWORD=root,
PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
);

Specifying Java Database Connectivity (JDBC) connection parameters, such as useSSL, is supported only with URL form.

ALTER RESOURCE

Use ALTER RESOURCE to modify the connection information of storage nodes, such as changing the size of a connection pool or modifying JDBC connection parameters.

Syntactically, ALTER RESOURCE is identical to ADD RESOURCE.

ALTER RESOURCE resource_2 (
HOST=127.0.0.1,
PORT=3306,
DB=db2,
USER=root,
PROPERTIES("maximumPoolSize"=50)
),resource_3 (
URL="jdbc:mysql://127.0.0.1:3306/db3?serverTimezone=GMT&useSSL=false",
USER=root,
PASSWORD=root,
PROPERTIES("maximumPoolSize"=50,"idleTimeout"="30000")
);

Since modifying the storage node may cause metadata changes or application data exceptions, ALTER RESOURCE cannot be used to modify the target database of the connection. Only the following values can be modified:

• User name
• User password
• PROPERTIES connection pool parameters
• JDBC parameters

DROP RESOURCE

Use DROP RESOURCE to delete storage nodes from a schema without deleting any data in the storage node. The statement example is as follows:

DROP RESOURCE resource_0, resource_1;

To ensure data correctness, the storage node referenced by the rule cannot be deleted.

t_order is a sharding table, and its actual tables are distributed in resource_0and resource_1. When resource_0 and resource_1 are referenced by t_order sharding rules, they cannot be deleted.

SHOW SCHEMA RESOURCES

SHOW SCHEMA RESOURCES is used to query storage nodes in schemas and supports the following syntax forms:

#Query the storage node in the current schema
SHOW SCHEMA RESOURCES;
#Query the storage node in the specified schema
SHOW SCHEMA RESOURCES FROM sharding_db;

For example, add four storage nodes through the ADD RESOURCE command, and then execute a query:

Image by:

(Jiang Longtao and Lan Chengxiang, CC BY-SA 4.0)

There are many columns in the query result, but here we only show part of them.

Conclusion

In this article, we have introduced you to the ways you can dynamically manage storage nodes through DistSQL.

Unlike modifying YAML files, executing DistSQL statements happens in real time, and there is no need to restart the proxy or compute node, making online operations safer. Changes executed through DistSQL can be synchronized to other compute nodes in the cluster in real time through the register center. The client connected to any compute node can also query changes of storage nodes in real time.

If you have any questions or suggestions about Apache ShardingSphere, please open an issue on the GitHub issue list. If you are interested in contributing to the project, you're very welcome to join the Apache ShardingSphere community.

Apache ShardingSphere Project Links:

• ShardingSphere Github
• ShardingSphere Twitter
• ShardingSphere Slack
• Contributor Guide

This article originally appeared on FAUN and is republished with permission.

A feature update to Apache ShardingSphere enhances the dynamic management of storage nodes.

Image by:

Jason Baker. CC BY-SA 4.0.

Databases What to read next Learn more about distributed databases with ShardingSphere This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Apple confirms iPadOS 16 delay - comments  GSMArena.com

Blackbox is an Aesthetically Pleasing Terminal for Minimalists Linux Users  It's FOSS

An improved user experience for all technical documentation on the Customer Portal was launched in May of 2022. The redesign rolled out several new features, including an all-new reading mode, expanding tables and an overhaul of the navigation and layout. The best part about the redesign? It was driven by customer feedback.

Firefox 105 Beta Brings Memory Fixes, Two-Finger Swipe Back/Forward Gesture on Linux  9to5Linux

Best Open-Source Distributions for Pentesting and Forensics | eSecurityPlanet  eSecurity Planet

Back in May there was a patch series by Google engineers working on encrypted hibernation support for Linux that would be protected by the platform hardware itself like with a TPM module as well as user authentication by a password or other means. Sent out today is a second revision to that Linux encrypted hibernation support...

Google Posts Updated Encrypted Hibernation Patches For Linux  Phoronix

Top 10 Best Linux Distros for Privacy and Security  hackernoon.com