I have a remote server on which I want to launch some gui applications inside a network namespace I have already setup. I am using socat to forward the x session.
socat exec:'ssh {REMOTE_HOST} rm -rf /tmp/.X11-unix/X1; socat -d -d -d -d unix-l\:/tmp/.X11-unix/X1111 -' unix:/tmp/.X11-unix/X0
However, if I try to launch an application like eog
DISPLAY=:1111 eog
It fails with the following message:
I No protocol specified
** (eog:9498): WARNING **: Could not open X display
Cannot open display:
Run 'eog --help' to see a full list of available command line options.
And socat exits immediately afters.
Well, it took a day but I figured a way to do it.
I ended up using Xpra to start an X-server at the remote server and attached to it in my local machine.
The socat approach worked too after running xhost + locally and adding the fork flag in the socat invocation at the remote server . However, it never worked consistently (There was as much chance the application to hang during launch as not). And it never worked with more complex applications like firefox. Stracing the apps pointed towards the applications hanging when trying to use dbus.
Related
Anyone had success adding MySQL to a Windows docker image? I tried two different ways of deploying MySQL to my image.
I tried using the msi from MySQL in non-interactive mode. Does not work at all in a container.
While Installing Mysql.msi through powershell getting below error
I tried extracting the zip to set things up manually using the mysqld commands does nothing at all. Literally nothing, the exectutables behave as if they just run and exit (no output, nothing):
https://github.com/Somesh-K/Automation-Mysql/blob/main/1.mysql_setup_v2.ps1
Something is very weird about all of this.
Yes, I know that there's a perfectly good MySQL docker linux container published by Oracle to Docker hub. This works. The problem is that running a Windows container and Linux container that need to interact creates a really unnecessary frustration for the user in terms of networking between the two.
Using a different back-end (like SQL server) for our application is not feasible and using .NET core instead of .NET framework is not feasible. To simplify, I'd like to just install MySQL on our windows based webserver docker image. This seems do-able using the two methods described in the links above, but as noted, it does not work and there's very odd behavior from the MySQL binaries when they are run in the container.
Here's an example of the odd behavior:
Install Docker Desktop for Windows
Download the Win32 install zips from MySQL and place in C:\mydata
https://dev.mysql.com/downloads/mysql/
Pull down the ASPNET image from Docker Hub, Run it, and Open up Powershell:
# docker pull mcr.microsoft.com/dotnet/framework/aspnet:4.8
# docker run --name testweb -v C:\mydata:C:\mydata:R -d mcr.microsoft.com/dotnet/framework/aspnet:4.8
# docker exec -it testweb powershell
C:\ > cd C:\mydata
C:\mydata\ > Expand-archive -path .\mysql-5.7.36-winx64.zip .
C:\mydata\ > cd \mysql-5.7.36-winx64\bin
C:\mydata\mysql-5.7.36-winx64\bin\ > .\mysql.exe -version
[zero output, acts like it's an empty executable]
Results
None of the executables/binaries in the extracted mysql bin directory on the container do anything at all. They behave as if someone wrote and executable that just exits. I thought I had a bad install zip so I extracted the same zip on my regular Windows 10 workstation. All of the binaries at least return errors or do something.
This is super odd. Any help would be appreciated.
Downloading this executable and putting it into my container seemed to do the trick:
https://download.microsoft.com/download/2/E/6/2E61CFA4-993B-4DD4-91DA-3737CD5CD6E3/vcredist_x64.exe
Placed this on my container and started it
C:\vcredist.exe /Q
After doing this, the executables starting working:
C:\ > cmd.exe /C "C:\mysql\bin\mysqld" --initialize-insecure
C:\ > cmd.exe /C "C:\mysql\bin\mysqld" --install
C:\ > start-service mysql
C:\ > cmd.exe /C "C:\mysql\bin\mysql" -u root
This is my first post here, I post because after reading through X articles googling can't get PhpStorm, Xdebug work with CLI scripts.
Already tried to follow advices from:
PHPStorm + XDebug Setup Walkthrough
https://confluence.jetbrains.com/display/PhpStorm/Zero-configuration+Web+Application+Debugging+with+Xdebug+and+PhpStorm
PHPStorm + XDebug + Vagrant
and few blogs that I've found online, but still nothing...
I had it working, but after destroy vagrant recently and now can't fully restore this feature.
SETUP:
I'm running Symfony project on Vagrant.
Debugging of "webpages" on my server works just perfectly.
When I try debug CLI Command I prequisite it with:
export XDEBUG_CONFIG="XDEBUG_SESSION=1"
export PHP_IDE_CONFIG="serverName=vagrant"
XDEBUG.INI (on Vagrant):
zend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_host=192.168.0.133 (ip I get from ifconfig -a on Vagrant)
xdebug.remote_port=9000
xdebug.max_nesting_level=2500
xdebug.remote_handler=dbgp
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.idekey="PHPSTORM"
Any help much appreciated. Digged through X articles on web but in my eyes all configurations look ok, no idea what to do...
Set xdebug.remote_connect_back to be 0.
This option prevents you from using right IP address when you are doing Remote CLI debugging. Since it's a CLI debug, the IP will always be local (vagrant machine) while you need another one.
This option works OK when debugging over browser as request comes from your "real" computer. But when doing CLI debug .. request will be local to Vagrant machine.
When this option is set to 1 (as it is done now) it ignores the setting from #2 below.
xdebug.remote_host=192.168.0.133 (ip I get from ifconfig -a on Vagrant) -- this should be an IP of your computer where PhpStorm is running as seen from Vagrant machine.
Combination of those 2 above will do the job for you.
I'm learning how to build a basic OS kernel with https://intermezzos.github.io
I've create my .iso file and I'm at the point where I am runnning qemu-system-x86_64 -cdrom os.iso
When I press enter, QEMU runs a window with the following output:
Booting from Floppy...
Boot failed: could not read the boot disk
Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0004)
Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initializing devices...ok
iPXE 1.0.0+git-20131111.c3d1e78-2ubuntu1.1 -- Open Source Network Boot Firmware
-- http://ipxe.org
Features: HTTP HTTPS iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE Menu
net0: 52:54:00:12:34:56 using 82549em on PCI00:03.0 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:01]
Configuring (net0 52:54:00:12:34:56)...ok
net0: 10.0.2.15/255.255.255.0 gw 10.0.2.2
Nothing to boot: No such file for directory (http://ipxe.org/2d03e13b)
No more network devices
No bootable device.
I went to the website listed in the output (http://ipxe.org/2d03e13b) and one of the tips is that I might Use the iPXE command line to perform DHCP manually, however when I press CTRL + B to access cli, I'm not able to do so.
Where do I look next to troubleshoot this problem of not being able to boot my .iso?
How do I make QEMU have access to keyboard input?
UPDATE
I don't know how, but I'm am now able to use CTRL + B to access iPXE command line.
This seems like a good place to start diagnosing my problem of not being able to boot my .iso.
What am I looking for?
UPDATE 2
Thanks to Peter Maydell's suggestion below, I've tested a known-good iso image (https://alpinelinux.org/), running qemu-system-x86_64 -cdrom alpine-3.4.3-x86_64.iso and it booted perfectly just as I expected.
I've rewritten my files from https://intermezzos.github.io to create a new iso image, this time copy and pasting the code from the repository, just in case I was previously inputting typos.
Still not booting. On to the next clue...
The first thing to do is to check whether this command line and ISO image work on a normal Linux host system. That will tell you whether the problem is (a) the Windows Subsystem for Linux not correctly implementing something QEMU relies on or (b) your ISO image actually not being a bootable CDROM.
You might also try booting a known-good ISO image such as one for a Linux distribution.
(The general principle here is to try to do diagnostic tests to split the space of "what might be the problem" into smaller sections and determine which side your problem is.)
Simple solution to the problem. Has to do with systems that use EFI to boot.
source
I needed to apt-get install grub-pc-bin and then rebuild image.
I installed a PHP application on one of my gears in Openshift. It is a git clone from https://github.com/ThinkUpLLC/ThinkUp/tree/v2.0-beta.10. Something went wrong with the application and hence I would like to delete this application now. However I get an error as "Unable to perform action on app object. Another operation is already running." while trying to delete the application using rhc command tool. I have already tried using rhc app-force-stop, however it did not make any difference.
Sounds a bit like this bug - https://bugzilla.redhat.com/show_bug.cgi?id=997008. There seems to be no solution/workaround though.
Have you tried deleting the application via the web console?
You can try this command, this will kill all the background processes associated with the app.
pbrun /usr/sbin/oo-admin-ctl-app -l svc-<domain-id> -c destroy -a <app-name> -n <domain-id>
all my MySQL environment variables result in an empty string such as
echo getenv('OPENSHIFT_MYSQL_DB_URL');
echo getenv('OPENSHIFT_MYSQL_DB_HOST');
however the others such as
echo getenv('OPENSHIFT_APP_NAME');
echo getenv('OPENSHIFT_REPO_DIR');
work perfectlly fine. Any ideas what i am doing wrong?
I had the same issue, and tried creating and recreating Applications multiple times without success
The solution was to use Git to push the code to Openshift (at least one time), if you only use sFTP to push the code, those variables will not be accessible
You can just use the rhc app stop & rhc app start commands to restart your application and the environment variables will then be provided to your application. Make sure that you don't just use the rhc app restart command, as it doesn't not usually work, think of it as an apachectl stop/start vs apachectl reload.