I need to test an X11 application for its behavior when the X server does not use a backing store for the application's windows (see https://tronche.com/gui/x/xlib/window/attributes/backing-store.html). I.e., I want the server to ask the application to redraw "damaged" parts of the window by generating Expose events.
The problem is that on my current platform, Linux Mint 20.2 Cinnamon, the X server seems to always use backing store, and also when I don't ask for it.
I have also tried to install some old versions of Ubuntu (back to Ubuntu 14.04), but they also seem to always use backing store.
Question: Is there a way to disable use of backing store on Linux Mint 20.2 Cinnamon? If not, is there another recent Linux distribution where this is possible? If not, does anyone have any idea what I need to do to be able to test without backing store?
EDIT: Turns out that Ubuntu 10.04 has backing store disabled by default, i.e., the behavior that I am after, and Ubuntu 12.04 does not. However, it is a hassle to depend on Ubuntu 10.04 because it is no longer supported by Canonical. It would be great if anybody has input on how that behavior can be achieved on a contemporary distribution.
'backing-store' is a window attribute, which can be set either at window creation or via XChangeWindowAttributes.
e.g.
long attr_mask = CWBackingStore | CWEventMask;
XSetWindowAttributes attr = {
.backing_store = NotUseful,
.event_mask = ExposureMask //among others
};
XUnmapWindow(dpy, win); //maybe not necessary
XChangeWindowAttributes(dpy, win, attr_mask, &attr);
XMapWindow(dpy, win); //maybe not necessary
Note (see https://tronche.com/gui/x/xlib/window/attributes/backing-store.html):
A backing-store attribute of NotUseful advises the X server that maintaining contents is unnecessary, although some X implementations may still choose to maintain contents and, therefore, not generate Expose events.
Another possibility:
Start the xserver with the command line parameter (see man xserver)
bs disables backing store support on all screens.
Based on the comment below:
I don't understand why it should not be relevant to (be able to) 'disable' the backing-store via client? The value NotUseful disables backing-store for the specific window (if supported by the server, see Note above).
Otherwise, there are only two options left, either via command line argument (see above) or via xorg.conf.
e.g.
add in the directory (/etc/X11/)xorg.conf.d a file named 10-backing-store.conf with the following content:
Section "Device"
Option "BackingStore" "off"
EndSection
Restart X (or the machine) and see what happens (locate the log file Xorg.0.log - either in /var/log or ~/.local/share/xorg - and look for the token "Backing store", e.g. less Xorg.0.log | grep "Backing store").
Of course, both options requires super user privileges and a restart.
Related
I have an Ansible script to update and maintain my WildFly installation. One of my tasks in this setup is managing the MySQL-driver and in order to perform an update on that driver, I have to first disable the application that uses that driver, before I can replace the it and set up all my datasources anew.
My CLI script starts with the following lines:
if (outcome == success) of /deployment=my-app-1.1.ear:read-resource
deployment disable my-app-1.1.ear
end-if
My problem is that I am here very depending on the actual name of the application and that name can change over time since I have my version information in there.
I tried the following:
set foo=`ls /deployment`
deployment disable $foo
It did not work since when I look at foo I see that it was not my-app-1.1.ear but ["my-app-1.1.ear"] -- so I feel that I might be going in the right direction, even though I have not got it right.
We're developing an open source Python library that runs on Linux, MacOS, and Windows, but we don't have much experience or exposure to Windows in the developer team. The way we setup and run our test suite works fine under Linux and Mac, but is suboptimal on Windows.
Our tests set up a new directory in a temporary location, place a fake .gitconfig with relevant configurations inside it, and have the relevant HOME environment variables point to this location as the home directory in order to pick up the configurations during testing.
The code is shortened and can't be run, but hopefully illustrates the gist of what we do:
with make_tempfile(mkdir=True) as new_home:
pass
for v, val in get_home_envvars(new_home).items():
set_envvar(v, val)
if not os.path.exists(new_home):
os.makedirs(new_home)
with open(os.path.join(new_home, '.gitconfig'), 'w') as f:
f.write("""\
[user]
name = Tester
email = test#example.com
[more configs for testing]
exc = 1
""")
where get_home_envvars() makes sure that the $HOME env variable points to the new, temporary test home. On Windows since Python 3.8, os.path no longer queried the $HOME variable to determine a user's home, but USERPROFILE[1 ][2], so we've just overwritten this variable with the temporary test home:
def get_home_envvars(new_home):
environ = os.environ
out = {'HOME': new_home}
if on_windows:
# requires special handling, since it has a number of relevant variables
# and also Python changed its behavior and started to respect USERPROFILE only
# since python 3.8: https://bugs.python.org/issue36264
out['USERPROFILE'] = new_home
out['HOMEDRIVE'], out['HOMEPATH'] = splitdrive(new_home)
return {v: val for v, val in out.items() if v in os.environ}
However, we have now discovered that this breaks our test setup on Windows, with tests "bleeding" their caches, cookie data bases etc. into the places where we perform our unit tests, and with this creating files and directories that break our test assumptions.
I have a very limited understanding on what happens exactly, but my current hypothesis is this: Our library determines the appropriate locations for caches, logs, cookies, etc upon start by using appdirs [3], which does so by querying the "special folder" IDs/ CSIDLs that Windows has [4]. This information is determined in the Windows registry - which is found based on the USERPROFILE. To quote one specific reply in the Python bug tracker to this change:
This is unfortunate. Modifying USERPROFILE is highly unusual. USERPROFILE is the location of the user's "NTUSER.DAT" registry hive and local application data ("AppData\Local"), including "UsrClass.dat" (the "Software\Classes" registry hive). It's also the default location for a user's known shell folders and home directory. Modifying USERPROFILE shouldn't cause problems with any of this, but I'm not completely at ease with it.
After our testsuite setup is done, we start new processes that run our tests. The new processes only get to see the new USERPROFILE, and appdirs returns the paths it finds by sending them through normpath, which unfortunately interprets the empty string returned by _get_win_folder for a CSIDL that now can't be found anymore as a relative path (.):
# snippet from appdirs source code
path = os.path.normpath(_get_win_folder("CSIDL_COMMON_APPDATA"))
And based on this, we end up configuring the current working directory of each test as the place for user data, user caches, etc.
My question is: How could I fix this? Based on my probably incomplete understanding, I currently think it ultimately boils down to the question how to treat or mock the USERPROFILE. I need to have it pointed to a registry in order to derive the "special folder" IDs (be it with appdirs or more modern replacements of it) - but I also need it to point to the fake home with test-specific Git configurations. I believe the latter requires overwriting USERPROFILE in Python3.8 and newer. I'm wondering if there is a way to copy or mock the registry and place it under the new home? Set relevant CSIDLs/KNOWNFOLDERIDs in some other way? Hardcode other temporary locations to use as cache directories etc? Or maybe there is a more clever way to run a test suite under Windows that does not require a fake home?
I would be very grateful to learn from more experienced Windows developers what to do, or also what not to do. Many thanks in advance.
[1] https://docs.python.org/3.11/library/os.path.html#os.path.expanduser
[2] https://bugs.python.org/issue36264
[3] https://github.com/ActiveState/appdirs
[4] https://learn.microsoft.com/en-us/windows/win32/shell/csidl
I am running into a problem with labeling. In order to lock down access to a file /etc/avahi/avahi-daemon.conf I decided to label it as a part of the avahi_t domain.
I am working on an embedded system. When I boot up the system from a version update, the file system is relabeled with the .autorelabel flag set.
Unfortunately the file /etc/avahi/avahi-daemon.conf remains in the unlabeled_t type. Due to the label being wrong, it is unable to read the file and avahi fails to initialize properly with an avc read denied on an unlabeled_t file. I want to have the label correctly set and not modify policy to read an unlabeled file. I also want it to be protected so the configuration can not be modified.
I have properly labeled it in the .fc file with the following:
/etc/avahi/avahi-daemon.conf -- gen_context(system_u:object_r:avahi_t,s0)
When I try a restorecon on the file system it attempts to relabel the file but is blocked by SELinux with a relabelto avc violation. Similarly changing it with chcon -t fails to change it. I do not wish to open relabelto up on an embedded system as it can then be relabeled and take down the avahi initialization. If I take out the SD card, and relabel the file on a different system. And place it back into the target system it is properly labeled. And avahi operates correctly. So I am certain that the labeling is causing the problem.
In looking in the reference policy an init_daemon_domain(avahi_t,avahi_exec_t) is being performed.
In looking at the documentation for init_daemon_domain() it states the following:
"The types will be made usable as a domain and file, making calls to domain_type() and files_type() redundant."
This is unusual in that if I add files_type(avahi_t) to the .te file, it properly labels after version update.
I am really wanting to know more information about this, and unfortunately my searches on the internet have been less than fruitful in this regard.
Is the documentation for SELinux wrong? Am I missing something about init_daemon_domain() in that it only works with processes and not files?
Or is the files_type(avahi_t) truly needed?
I know this comes off as a trivial issue since there is a path to where it is working. However I am hoping to get an explanation as to why files_type(avahi_t) is necessary?
Thanks
I am working through the process for activating Kerberos on the Cloudera quick-start VM. The vm begins life with hostname = "quickstart.cloudera" but I had to change it to get it into our local DNS consistently. After changing the name I was able to get everything except impala to come up. The manager is passing it --hostname=quickstart.cloudera even though everything else in the whole system knows the new name. I don't strictly have to have impala running for the tests I need to run but it's driving me nuts. Any clues?
I'm looking at a relatively fresh install of CM 5.3 with Impala 2.1 and I don't see the hostname being passed to the catalog server via cmdline flags.
Unless you're explicitly setting the hostname parameter in CM via a safety-valve configuration (I assume you're not doing this), then Impala gets the hostname to use by calling the gethostname() stdlib function (see the gethostname() man page). The log output snipped you showed is somewhat deceiving because when the flag isn't set, Impala actually sets that value manually and it shows up as if it were passed by the user.
Anyway, you should check that the hostname is properly changed on the box,
which may depend on your OS. A few things to try: check the hostname command returns the name you expect and that you've restarted the OS.
I'm using Passwd::Keyring::Auto for Perl on Windows. I noticed that the keyring is not persistent.
Can I force it to be persistent on Windows?
http://search.cpan.org/~mekk/Passwd-Keyring-Auto-0.2703/lib/Passwd/Keyring/Auto.pm
Ex.
use Passwd::Keyring::Auto;
my $keyring = get_keyring(app=>"Test", group=>"Windows");
my $username = "someuser";
my $password = $keyring->set_password($username, $password, "mylostspace.com");
When my program ends, I'd like to get whatever passwords I had in the keyring like below:
$password = $keyring->get_password($username, "sometest.com");
However, the $keyring->is_persistent() always returns 0. I tried forcing the option PERSISTENT => 1 when I create the keyring, but that didn't work.
Thanks in advance
I simply haven't developed windows backend yet, as I do not own windows machine at the moment. Writing module like Passwd::Keyring::WindowsVault (or similar) should not be hard (especially considering one can consult python keyring library source for inspiration), but requires some programmer with Windows development environment. In case you are (or anybody else is) interested in writing one, I would be glad to help, but I am simply unable to test such a module or even to prepare binary distribution for CPAN.
Once such module exists, integrating it into Passwd::Keyring::Auto would be trivial
Pointers:
(what should Passwd::Keyring backend implement)
https://metacpan.org/pod/distribution/Passwd-Keyring-Auto/lib/Passwd/Keyring/Auto/KeyringAPI.pm
(APIs used by pythonic library)
https://bitbucket.org/kang/python-keyring-lib/src/8aadf61db38c70a5fe76fbe013df25fa62c03a8d/keyring/backends/Windows.py?at=default
(in perl it should be replaced with some XS as I do not know about anything like ctypes, module code structure would likely be similar to that of https://bitbucket.org/Mekk/perl-keyring-gnome/src )
And one more note: with some effort it should be possible to use Passwd::Keyring::PwSafe3 backend on Windows, to keep passwords persistent. You will still need to provide opening password for this storage (no open thanks to OS authorization) on every run but in case you have multiple passwords or want to manage them from GUI too it may make sense. You can try setting environment variable PASSWD_KEYRING_AUTO_PREFER to PwSafe3 to use this keyring (of course install the module beforehand).