This question was already https://stackoverflow.com/questions/13192322/how-to-change-home-directory-of-jenkins on Stack Overflow. I'll copy the top answer here, but there are several other answers over there that you may find useful: For me on Jenkins 2.7.2 on RHEL 7.2 after already starting jenkins and configuring a build, I needed to: Change the jenkins user's home directory sudo su - service jenkins stop vi /etc/passwd # change the /var/lib/jenkins to /home/jenkins or whatever Change the setting in the start script to also find it vi /etc/sysconfig/jenkins # change the JENKINS_HOME to /home/jenkins or what ever Copy all the data to the new location (eg: /home/jenkins) cd /home cp -Rf /var/lib/jenkins . chown -R jenkins:jenkins * Start it back up service jenkins start And that seems to have done it for me.

If the container needs to connect to a host or a remote service, you need his ip or domain. Any other workaround only will work on your laptop or is just for academic purposes, not valid in the real scenarios with real users. For example: a container in aws needs to connect to an azure mysql. In your case, you need the local ip. As I explained here https://stackoverflow.com/a/52213178/3957754 you could get the ip before the docker-compose up: export MACHINE_HOST_IP=$(hostname -I | awk '{print $1}') docker-compose up ... And in your compose file use this value. For example of you have a mysql on your host and your container need it, you could use: version: '3.2' services: wordpress: environment: DB_HOST : ${MACHINE_HOST_IP}:3306 DB_USER : usr_wordpress Review: https://stackoverflow.com/questions/52173352/what-is-the-difference-between-publishing-808080-and-80808080-in-a-docker-run/52213178#52213178 https://stackoverflow.com/questions/63136530/how-to-connect-api-with-web-spa-through-docker/63207679#63207679

https://bugs.launchpad.net/cloud-init/+bug/1966533 I was getting silent failures because the hostname was host-10-2-65-89.openstack.build. Instead of host-10-2-65-89.openstack.build What actually happens is, $ sudo hostname host-10-2-65-89.openstack.build. hostname: the specified hostname is invalid Background, what I was actually doing was using Terraform, fqdn: "${fqdn}" And then setting the fqdn like this, fqdn = openstack_networking_port_v2.port_company.dns_assignment[0].fqdn But the problem is the terraform was return the actual FQDN, host-10-2-65-89.openstack.build. But you can't provide that to hostname. My solution was to remove the dot (.) with https://www.terraform.io/language/functions/trimsuffix fqdn = trimsuffix( openstack_networking_port_v2.port_company.dns_assignment[0].fqdn, "." )

Depending on what you want to do, there are a lot of options you can pass in to docker, but if you just want to run the code in the container as written: docker run nvcr.io/nvidia/pytorch:18.04-py3 or docker run c3555fec4fe6 or even docker run c3 you can give your docker images a more reasonable name with docker image tag nvcr.io/nvidia/pytorch:18.04-py3 pytorch and run that with docker run pytorch see man docker-run man docker-image-tag and https://docs.docker.com/engine/reference/commandline/run/

This is because ubuntu16 is no longer supported by Nvidia They have shut this repo down visiting the error page shows they have marked it as unsupported https://nvidia.github.io/libnvidia-container/ubuntu16.04/x86_64 check out the below for supported versions https://nvidia.github.io/libnvidia-container/

Asked on the Docker forums - apparently to correctly "import" the image, you don't user the import command but instead user image load command. INCORRECT: $ docker image save local/ubuntu:latest -o ubuntu.tgz # on Ubuntu 20 $ docker import ubuntu.tgz local/ubuntu:latest # WRONG! on Ubuntu 21 CORRECT: $ docker image save local/ubuntu:latest -o ubuntu.tgz # on Ubuntu 20 $ docker image load -i ubuntu.tgz # on Ubuntu 21 Credits go to the person who https://forums.docker.com/t/same-image-refuses-to-run-on-ubuntu-21-but-runs-on-ubuntu-20-docker-versions-are-the-same/121955 on the Docker forum here. Also note, that if you run docker image save the image full name (repo/name:tag) is actually save with along with other information, so upon running docker image load -i ubuntu.tgz Docker will tag that image as exactly as it was tagged when it was saved. If an image with the same name exists, it will be replaced, so be careful.

According to https://www.reddit.com/r/linux_gaming/comments/sbv42l/tutorial_how_to_play_origin_games_through/hu35ppu?context=3 Proton is bad for non-Steam games. The gist of it is that Proton is creating a container with everything it needs and circumventing that effectively negates using Proton. Lutris is considered a best alternative; it's been around for many years and supports a lot of games and launchers, and it's also Wine-based like Proton. As for the issue there seems to be a variety of problems: . at the start of a path points to "the directory this program was started from". If you're using the long path listed above to point the Steam/Origin client to the game it's likely interpreting it something like "./.steam/debian-installation/steamapps/compatdata/4132860189/pfx/drive_c/Program Files (x86)/Origin Games/Mass Effect Legendary Edition/&./.steam/debian-installation/steamapps/compatdata/4132860189/pfx/drive_c/Program Files (x86)/Origin Games/Mass Effect Legendary Edition/Game/ME3/Binaries/Win64/MassEffect3.exe", which is clearly just broken (& for separating the combined paths, not an actual part of it). \ does not work for paths on Unix-like systems as it "escapes" the next character. So, \P may be getting converted to a single character, which destroys the path. On the other hand / does work for paths on Windows. Using an absolute path rather than relative should help, though we already know getting this particular thing working would be a bad idea anyways. Relative paths begin with ./ or ../, so they can start from wherever. Absolute paths start at the root of a storage device, like / on Unix-like systems or C:\ on Windows. It's like using "follow the landmarks" directions vs following someone who definitely knows the way.

I'm pleased to say the people over at Mesa3D (the graphics library I use) found a temporary fix. Running the game with the INTEL_DEBUG=nofc flag fixes the issue.

Version 7.1 works best. Lutris Version 7.1 works better than 7.2. It is stable and it does not have the black quad bug, so you can finish your missions. It is the best version, I could play without any problems. Edit: Version 7.1 and 7.2 crashes instant action (skirmish mode). It won't open the menu to select the skirmish map. Sometimes you get a black screen after the mission finished and you can't click okay. Just start the game with an older lutris version, watch the end mission cinematics (or just cheat) and click on okay. Happens rarely, but it happened one or two times.

There is ProtonDB, a database which tracks Proton compatibility: https://www.protondb.com/app/221100

For completion sake, I accidentally obfuscated my root folder from SQL Developer. I was able to fix it by deleting all my old config files.

What you needed to set up was "dual-Primary" (aka "dual master"). This is where each of the two servers was both Primary and Replica to the other. That way, you would already have set up the replication mechanisms so that failover and fallback would be the same process.

It is correct that InnoDB tablespace files never shrink. There may be unused space within a large file after you delete a lot of rows, but the file still occupies a lot of space on your filesystem. The only way to make the file smaller is to copy the remaining data to a new tablespace and then drop the original tablespace. This is what the ALTER statement you described does. Alternative forms of this statement are: ALTER TABLE FORCE; OPTIMIZE TABLE ; They all do the same thing. I like the one with FORCE because it's most clear to me what it's doing. Copy a lot of data to a new tablespace takes a long time, and blocks access to the table while it's running. What I've done at some jobs in the past is to use the free tool https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html to run this task without blocking access to the table. It may in fact take longer than it does to run the ALTER TABLE directly, but since it does not block access, that does not cause an outage, so no one gets upset that it takes a long time. We have run this on tables much larger than the one you describe, so large that it took days to complete. You use MariaDB. I don't, and I have never personally used pt-online-schema-change with MariaDB. But I understand from other users that it works the same, since MariaDB is similar enough to MySQL that the features needed by pt-online-schema-change work the same. MariaDB is not the same product as MySQL, but in this case it is close enough.

sudo apt install postgis postgresql-13-postgis-3-scripts create extension postgis;

1.use pt-table-checksum tool for master and slave data 2.skip the error mysql> stop slave; mysql> set @@session.gtid_next='xxxxx'; mysql> begin; mysql> commit; mysql> set @@session.gtid_next=automatic; mysql> start slave; mysql> show slave status \G

That is probably CHARACTER SET ucs2. mysql --default-character-set=ucs2 -u root -p database < dumpfile.sql That does not impact what charset is used in the tables, only for reading the file. History MySQL 5.0.67 (Aug, 2008): "ucs2 does not work as a client character set, but attempts to use it as such were not rejected. Now character_set_client cannot be set to ucs2. This also affects statements such as SET NAMES and SET CHARACTER SET. (Bug #31615)". MySQL 8.0.28 (Jan, 2022): ucs2, macroman, macce, dec, hp8 and "their collations in SQL statements or elsewhere in the MySQL server now produces a deprecation warning." (That is, they are still supported, but not for very long.) Conclusion: It may not be possible to import that data.

Based on some of the comments on https://github.com/ValveSoftware/steam-for-linux/issues/730 , this message is triggered if Steam is unable to launch a child process by executing a script which it creates under the affected library. Here are some reasons why that might happen: The script lacks execute permission in its filesystem mode (the x flag in ls -l's output). But Steam created this script, and it should have set the appropriate permissions automatically. Fix with https://linux.die.net/man/1/chmod . Any directory in the path to the script lacks execute permission. But I would expect this to cause much more substantial problems because you would be unable to even browse your Steam library in the file explorer. You can also fix this with chmod(1). Do not pass the -R flag unless you are sure you know what you are doing. Steam is running as a different user, which is not the normal way of setting things up, and that user lacks permissions as above. You may need to either chmod the library to add permissions, set up group permissions with https://linux.die.net/man/8/groupadd and https://man7.org/linux/man-pages/man1/chgrp.1.html , and/or use https://linux.die.net/man/1/chown to give the library (recursively if necessary) to Steam's user. Or you may simply need to make sure that Steam is running as you and not as some other user. The drive is mounted noexec, which prevents anyone from executing any binaries on the filesystem. Some Linux distributions do this automatically for removable drives, as a security measure, but I think we can rule this out based on your mount output. For completeness, this can be temporarily fixed with https://linux.die.net/man/8/mount but the permanent fix will depend on how your OS is mounting the drive. https://man7.org/linux/man-pages/man3/system.3.html is unable to find /bin/sh. But then your whole OS should be broken. A security tool such as SELinux or AppArmor is preventing Steam from executing binaries on this drive. These are very complicated to monkey around with. Some of the discussion on that bug suggests it might be a problem with case sensitivity. Try renaming the library (and in particular, the SteamApps subdirectory) to all lowercase. If you try to run that script yourself (it should be named .steam_exec_test.sh, and may not be visible unless you show hidden files), it may provide output to help you further diagnose the problem.

I'm going to answer this question a different way. When we're talking about database servers, the data within said databases is typically far more valuable than anything sitting on the file system. Database servers can be brought back online, databases can be restored from backups, etc... Not to diminish the fact that a user with OS access can wreck havoc and take a database offline. I'd be far more concerned what a malicious user would do to a database with write permission. They can manipulate data, delete data, insert bad data, etc. If a user is truly wanting to be malicious, this is all the access the would need to be destructive. Depending how aggressive they are, data changes could go undetected for weeks or months, making the chance of recovery challenging. So in this case, what are you trying to protect against? Preventing a trusted database users from making accidentally changes at the OS level? Making sure the scope of a malicious user is limited?

The key point here is a missing dependency: libqt5sql5-odbc and/or libqt5sql5-tds. Here a complete guide: Install ODBC and FreeTDS packages: sudo apt install unixodbc odbcinst freetds-bin tdsodbc Install additional packages required by QGIS for ODBC connection: sudo apt install libqt5sql5-odbc libqt5sql5-tds Install Microsoft SQL Server driver following the instructions on https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server Check the content of /etc/odbcinst.ini to make sure FreeTDS and MS SQL Server drivers are listed: [FreeTDS] Description=v0.91 with protocol v7.2 Driver=/usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so [ODBC Driver 18 for SQL Server] Description=Microsoft ODBC Driver 18 for SQL Server Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.0.so.1.1 UsageCount=1 Create a MS SQL Server datasource in /etc/odbc.ini according to example below: [ODBC Data Sources] MSSQLQGIS = ODBC Driver 18 for SQL Server [MSSQLQGIS] Driver=ODBC Driver 18 for SQL Server Description=QGIS Sql Server Server=tcp:<mssql host name/ip>,1433 TrustServerCertificate=Yes Make sure Driver and the value after datasource name match the name of driver listed in /etc/odbcinst.ini Test your connection with isql command template: isql -v e.g.: isql -v MSSQLQGIS jhon pwd321 Rename, delete or backup files /usr/local/etc/odbc.ini and /usr/local/etc/odbcinst.ini Create symbolics links to odbc ini files: sudo ln -s /etc/odbcinst.ini /usr/local/etc/odbcinst.ini sudo ln -s /etc/odbc.ini /usr/local/etc/odbc.ini In GIS Desktop, add a MSSQL connection as the example bellow:

max_connections = 500000 No! That the max simultaneous connections. Recommend 1000 until you can demonstrate a need for more. Also lower max_user_connections. 10k node js instances If that doesn't choke MySQL, it will choke the webserver. If this is a "stress test", then dial it back. When you find how big a burst you can handle, then ask how you will get that many jobs across the network, through only 64 cores, into the web server's queue, etc. A more realistic test is to crank it up from, say 100, until things saturate and it all goes to hell in a handbasket. nothing executes for a long time MySQL's logic is to give each connection a fair share. The result is that all connections take "forever" to finish. Would you send 10K people into a grocery store all at the same time? Space them out; then measure "completions per second". Another tip. It is best to throttle the thundering herd at the webserver. by 1000 at a time it somehow operates much better and does not hangs I see you have figure out what I just said.