EK0's questions

I need to run an application on X11 in Rocky Linux 9.2, on a machine that uses a touchscreen monitor in addition to a mouse and physical keyboard.

When I launch the application by touching its icon, the application window comes up together with the on-screen keyboard. The application window shifts up to make room for the keyboard. The user must dismiss the keyboard to make the window move down into the screen (otherwise, the application cannot be used as a large portion of the window moves above the edge of the screen).

Besides the minor annoyance of having to dismiss the on-screen keyboard, sometimes the window comes up in a shifted state, leaving room for the keyboard, but the keyboard does not appear. In that case, there is no keyboard to dismiss, and the window cannot be moved down without knowing the special keyboard shortcut to move the window when its title bar is not visible. This makes the application very inconvenient to use, especially since it is intended for non-technical users.

I have seen various posts showing how to configure GNOME using a browser extension and a connector to disable Caribou, the on-screen keyboard application, but apparently, the extension or the connector is no longer compatible with the version of the GNOME shell that comes with Rocky Linux (version 40.4.0).

Apparently, Caribou shows up even when the Settings > Accessibility configuration indicates that the on-screen keyboard should be disabled. By the way, the on-screen keyboard does not seem to appear at all when running Wayland instead of X11, but the application unfortunately is not compatible with Wayland.

Can anyone tell me what the correct way to get rid of the on-screen keyboard with the latest version of GNOME on Rocky Linux/X11?

I have an application that submits tasks to cloud services that create certain time-sensitive assets. The services take an unknown amount of time to process, and in addition the assets may be scheduled to go public even further in the future, so that I need to wait until the processing is complete and possibly longer after that until the asset is "public". At that point, I need to purge some caches to make the asset visible.

The cloud services can be passed a callback URL, so that they can notify me when the processing is complete. I have created a web service on CentOS 7 Apache that handles the callbacks. (FYI: the web service is implemented in Ruby using Passenger Phusion, with rack running on top of it.)

My idea was to have the callback schedule a system at job to purge the caches if the asset has been processed, but is not public yet.

The problem is that SELinux will not let Apache schedule an at job. Using audit2allow, I have added the following modules based on the failed operations logged in the audit.log.

ausearch -c 'unix_chkpwd' --raw | audit2allow -M my-unixchkpwd
semodule -i my-unixchkpwd.pp
ausearch -c 'at' --raw | audit2allow -M my-at
semodule -i my-at.pp
ausearch -c 'lspci' --raw | audit2allow -M my-lspci
semodule -i my-lspci.pp

The result is that now no failures are logged in audit.log, but the at command still fails.

When enforcing is on, the only thing I see in /var/log/messages is:

at: System error

Also, the standard error of the at command produces:

PAM failure: System error

But if I setenforce 0 everything works perfectly.

So even though it has to be SELinux that is preventing the at job from being scheduled, there doesn't seem to be any way to tell it to allow Apache to do it.

For now, I am having to write two different programs, one to handle assets that are public right after they are created, and another to handle assets that are scheduled at a known time in the future. If I need to handle arbitrarily scheduled assets, then I will have to implement my own version of the at scheduler. I would like to avoid such complications, if possible.

Any ideas as to how to find out what SELinux is objecting to would be appreciated (also any suggestions as to how this could be implemented without using at).

I installed and later removed the MongoDB server on a CentOS 7 box.

While cleaning up, I noticed that the ports assigned to MongoDB were still open. if I remember correctly, I was able to delete the main port (28017), but there are still two ranges defined:

$ sudo semanage port --list | grep mongo
mongod_port_t                  tcp      27017-27019, 28017-28019

When I try to remove the ranges, I get an error:

$ sudo semanage port -d -p tcp -t mongod_port_t 27017-27019
ValueError: Port tcp/27017-27019 is defined in policy, cannot be deleted
$ sudo semanage port -d -p tcp -t mongod_port_t 28017-28019
ValueError: Port tcp/28017-28019 is defined in policy, cannot be deleted

I have looked for any modules referring to MongoDB, but there does not seem to be anything there:

$ sudo semodule --list # => nothing mongo-related

Is there any way to find out in which policy the ports are defined? Or is there some other way to remove these ranges?

Thank you.

I am in charge of a site using Apache 2.0 on Red Hat 4.1.2.

I have configured the site to display a custom error page by adding this line to the .htaccess file in the site's root directory:

ErrorDocument 403 /403.html

For testing, I have blocked my own IP address in the site application; this results in something like this in the .htaccess file (I've edited the list for brevity and altered the IPs):

SetEnvIfNoCase REMOTE_ADDR "^(0\.0\.0\.1|0\.0\.0\.2|0\.0\.0\.3).*" BadIP
deny from env=BadIP

When I try to access the site from a "bad" IP, I get the custom error page if I try to get a specific page (for example, http://example.com/index.html).

However, if I try to get just the root directory (for example http://example.com), then I get the Apache test page instead.

Is there any way to get the root directory for the site to work with the custom error page?

EDIT: I think I may have caused some confusion. To clarify:

• when I try to get the root URL, the root page is not served; what I get is the page that says, "If you can read this page, it that means that the Apache HTTP server installed at this site is working properly." So I am blocked as expected, but I'm just not getting the 403 error page.
• when I try to get anything below the root, I get my custom 403.html page

UPDATE:

I've tried this on a more recent Apache version (2.2.25). I have also tried it without the ErrorDocument directive or SetEnv stuff. The .htaccess file contains only these 3 lines:

order allow,deny
allow from all
deny from 0.0.0.0

where 0.0.0.0 is replaced by my actual IP address.

The result is the same: when getting example.com I get the Apache "If you can read this" test page, and when getting example.com/x I get the built-in "Forbidden ... you don't have permission to access /x on this server" page.