There are many questions similar to mine (e.g. xdg-open not open default browser or xdgutils - xdg-settings not setting default-web-browser in gentoo, but none of the answers helped in my case. Therefor I ask for my particular situation:
On Centos 7 I have no free desktop manager running, I just run some X11 applications (like VS Code) from the command line where the DISPLAY variable is set to the X server on the (Windows) machine I connect from.
On the Centos machine I have two browsers installed, firefox and google-chrome. I can start both browsers just by typing firefox resp. google-chrome in the bash terminal.
xdg-open is available and it opens links in google-chrome - as does VS Code. However I want to change this to firefox.
I tried:
Ticking "Default browser" in Firefox's GUI preferences.
Using xdg-settings, but
xdg-settings get default-web-browser
returns "xdg-settings: unknown desktop environment"
Setting $BROWSER. In bash I issued
export BROWSER=firefox
but still google-chrome is started by xdg-open
How can I set in this environment the default browser to firefox?
Note: Strangely on another machine with Centos 6 (and "no desktop environment" either) the export BROWSER method works!
The desired behavior can be set in the mimeapps.list configuration files described in the XDG MIME Applications specification.
TLDR:
In order to configure firefox as the default browser for your user create ~/.config/mimeapps.list containing the following lines:
[Default Applications]
x-scheme-handler/http=firefox.desktop
x-scheme-handler/https=firefox.desktop
x-scheme-handler/ftp=firefox.desktop
x-scheme-handler/chrome=firefox.desktop
text/html=firefox.desktop
application/x-extension-htm=firefox.desktop
application/x-extension-html=firefox.desktop
application/x-extension-shtml=firefox.desktop
application/xhtml+xml=firefox.desktop
application/x-extension-xhtml=firefox.desktop
application/x-extension-xht=firefox.desktop
Details:
xdg-utils like xdg-open(1) and xdg-mime(1) look for this file in the locations listed under the File name and location section of this specification:
$XDG_CONFIG_HOME/$desktop-mimeapps.list user overrides, desktop-specific (for advanced users)
$XDG_CONFIG_HOME/mimeapps.list user overrides (recommended location for user configuration GUIs)
$XDG_CONFIG_DIRS/$desktop-mimeapps.list sysadmin and ISV overrides, desktop-specific
$XDG_CONFIG_DIRS/mimeapps.list sysadmin and ISV overrides
$XDG_DATA_HOME/applications/$desktop-mimeapps.list for completeness, deprecated, desktop-specific
$XDG_DATA_HOME/applications/mimeapps.list for compatibility, deprecated
$XDG_DATA_DIRS/applications/$desktop-mimeapps.list distribution-provided defaults, desktop-specific
$XDG_DATA_DIRS/applications/mimeapps.list distribution-provided defaults
The locations for the $XDG variables are governed by the XDG Base Directory specification. If you want to figure out where xdg-utils are looking for configuration in your particular case, run them with the XDG_UTILS_DEBUG_LEVEL environment variable like so:
$ XDG_UTILS_DEBUG_LEVEL=10 xdg-open 'https://www.example.com'
...
Checking /home/USERNAME/.config/mimeapps.list
...
Related
I can connect to a remote host using Kerberos in PuTTY on Windows 10, but I cannot do the same thing in VS Code.
In PuTTY, there is a setting (see below) that specifies the order of GSSAPI libraries:
Since this answer states that Windows "has two Kerberos libraries (MIT KfW & Windows SSPI)", I suspect that VS Code is not defaulting to the correct, MIT Kerberos GSSAPI64.DLL library.
But I can't seem to find any answers online that shows how to specify the preference or order of such libraries in my ssh config file.
Any suggestions are welcome! Thanks in advance.
There is no way to do that.
When VSCode makes an SSH connection, it normally uses the ssh.exe program from OpenSSH rather than using PuTTY.
PuTTY has been deliberately written to load the libraries on the fly (to avoid the .exe having any hard dependencies), so its ability to configure the library paths is there "for free". That's not the case for OpenSSH, however, or even most other Kerberos-using programs – ssh.exe is "hard" linked to one specific library at compile time; it can dynamically load PKCS#11 backends but hasn't been programmed to dynamically load GSSAPI backends.
In addition, Windows SSPI actually provides a different API from that of GSSAPI – the core concepts and flows are the same, but the function names and prototypes differ quite a bit. Again, PuTTY supports both only because it was deliberately written to do so. Standard OpenSSH would only support GSSAPI, and while Microsoft has patched the "in-box" Win32-OpenSSH to use SSPI, it is still one or the other – you can't really make the Windows ssh.exe load MIT libgssapi instead.
There are several workarounds, though:
You can try installing a different OpenSSH build for Windows that does use GSSAPI from MIT Kerberos; perhaps either Cygwin OpenSSH, or the MSYS OpenSSH that's included with Git could work (if it has GSSAPI support at all).
You can try configuring VSCode to run PuTTY's command-line SSH client plink.exe instead of ssh.exe. This likely won't work for interactive shell sessions, but might be able to handle non-interactive ones (such as VSCode Remoting).
You can try using Windows SSPI, as it does not actually require domain membership to work as a Kerberos client – it's enough to save your Kerberos credentials in Windows:
cmdkey /add:*.example.com /user:sam#EXAMPLE.COM /pass
Note that if the realm is not running Active Directory, you also need to mark it as a "MIT realm" as an Administrator (the presence of a "realm flags" setting – even an empty one – is needed to prevent Windows from doing AD-specific Netlogon probes):
ksetup /addrealmflags EXAMPLE.COM TcpSupported
With the password stored, enabling GSSAPIAuthentication yes in your ~.ssh\config will allow Windows OpenSSH (as well as PuTTY with SSPI) to connect using Kerberos to any host matching the specified *.example.com.
I am using Google's Datastore (which is Firestore's support for the GCP) and the emulator to handle storage locally. Everything works fine as far as storing data. But there does not appear to be any way of actually viewing the data in the browser. I have a feeling that this is not yet implemented because the emulator is still in beta. Has anyone been able to view data in their browser? It should be stressed that this is the emulator provided by the Google Cloud Platform SDK and not the one that Firebase uses for its products. The emulator is started with:
gcloud beta emulators datastore start
As of January 2022
Debugging
Setting up Firebase Datastore Emulator (FDE)
The Firebase Datastore Emulator (FDE) emulates the Google Datastore in App Engine. This is meant to run on Java 8 platforms. When correctly setup, any Datastore operations are done locally and stored to a file called local_db.bin.
The documentation for using the Firebase Datastore Emulator can be found at:
https://cloud.google.com/datastore/docs/tools/datastore-emulator
It should be noted that this documentaton contains errors and is missing some important settings. To use Firebase Datastore Emulator, install the emulator by running the following command from a terminal:
gcloud components install cloud-datastore-emulator
Start the emulator in a terminal:
gcloud beta emulators datastore start --data-dir=fbdatastore --host-port=localhost:8100
The official documentation does not indicate to use the --host-port flag. If you leave this flag out, a random port will be selected. But experience has shown that letting the port be randomly selected can result in exceptions generated by the client library used to access the local datastore - even when the port is correctly set in the environment variables.
The --data-dir flag indicates the directory where the local database file is stored. Here, it is specified as fbdatastore but you can use any folder located anywhere. You should make sure that the folder already exists before you start the emulator. In the example shown here, no path is included. This means that when you start the emulator, the directory specified by --data-dir should be in the same folder where you are launching the emulator.
The emulator will only create the local_db.bin file when you initially write data to it. If you don't write any data, it will not be created. Even it isn't created, the client APIs will still work correctly when reading from it, typically returning null values for any entities that you attempt to access. No exception will be thrown if the database file does not exist.
If the --data-dir is set to fbdatastore as used here, the local_db.bin file will be created under:
fbdatastore/WEB-INF/appengine-generated/local_db.bin
After the emulator has started, you can verify that it is running but opening a browser window and navigating to the url:
http://localhost:8100
This will only display the text "ok".
Before you can start debugging the app, several environment variables need to be set. You need to open a new terminal window and execute the following commands to set several variables:
export DATASTORE_DATASET=[project-id]
export DATASTORE_EMULATOR_HOST=localhost:8100
export DATASTORE_EMULATOR_HOST_PATH=localhost:8100/datastore
export DATASTORE_HOST=http://localhost:8100
export DATASTORE_PROJECT_ID=[project-id]
export DATASTORE_USE_PROJECT_ID_AS_APP_ID=true
The client libraries for the Datastore expect the app id to be used. But it was found that using only the app id didn't work. The environment variable DATASTORE_USE_PROJECT_ID_AS_APP_ID needs to be set as well. This is not specified in the documentation.
It should be noted that the official docs show the following:
export DATASTORE_DATASET=my-project-id
export DATASTORE_EMULATOR_HOST=::1:8432
export DATASTORE_EMULATOR_HOST_PATH=::1:8432/datastore
export DATASTORE_HOST=http://::1:8432
export DATASTORE_PROJECT_ID=my-project-id
For MacOS, this is wrong. The variables with values set to ::1 is wrong. Using this will cause exceptions and probably prevent the emulator from even loading. The ::1 needs to be replaced with localhost, as shown above.
You can just copy the 6 lines shown above and paste them into a terminal and hit Enter. But it is easier to just place these into a bash file and execute it. These need to be set before the local development server is started. The following bash file will set the environment variables and then start the development server:
export DATASTORE_DATASET=[project-id]
export DATASTORE_EMULATOR_HOST=localhost:8100
export DATASTORE_EMULATOR_HOST_PATH=localhost:8100/datastore
export DATASTORE_HOST=http://localhost:8100
export DATASTORE_PROJECT_ID=[project-id]
export DATASTORE_USE_PROJECT_ID_AS_APP_ID=true
java_dev_appserver.sh --address=0.0.0.0 --port=8080 --disable_update_check --jvm_flag=-Xdebug --jvm_flag=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 build/exploded-website
Replace [project-id] with the project id shown in your Googel Cloud Platform console (don't include the square brackets).
The address parameter for java_dev_appserver.sh is set here to 8000. You will need to set this in your IDE. Also, the port for java_dev_appserver.sh is set to 8080. You can set this to whatever works on your system and doesn't conflict with any existing ports used elsewhere. The last parameter for java_dev_appserver.sh is the location of your war files, which is the compiled app. Here, it is located at build/web-site. Replace this with the location of your own build files.
To view the datastore locally in your browser, navigate to:
http://localhost:8080/_ah/admin/datastore
Details on the command parameters used to start the emulator can be found at:
https://cloud.google.com/sdk/gcloud/reference/beta/emulators/datastore/start
As far as I can understand what you want to do is to add data in the Datastore emulator running on your console and be able to see this data in the UI right?
Vieweing the data in the UI actually incurs in expenses for you because Datastore have to query the data to be able to display it on the UI.
I can still recommend you to create a Feature Request if you want to be able to see the entries form the Datastore emulator for free in the UI
I'm a little bit fed up of this window:
I checked the configuration and I added the proxy URL to the http.proxy entry as described here:
"http.proxy": "http://frustratedusername:password#pesky.proxy.com:8080/"
But it didn't work. Then, I tried setting the http_proxy and https_proxy environment variables, but it didn't work neither.
Is there any way to make VS Code remember the proxy settings?
Remembering proxy credential should now be supported, since VSCode 1.51 (Oct. 2020), and confirmed with VSCode 1.52 (Nov. 2020)
Remember proxy credentials#
We are overhauling the login dialog that shows when a network connection requires authentication with a proxy.
A new setting, window.enableExperimentalProxyLoginDialog: true, will enable this new experience that we plan to make the default in a future release.
Theme: GitHub Light
The dialog will appear inside the VS Code window and offer a way to remember the credentials so that you do not have to provide them each time you start VS Code.
Credentials will be stored in the OS standard credential store (keychain on macOS, Windows Credential Manager on Windows, and gnome keyring on Linux).
We still only show this dialog once per session, but might revisit this decision in the future. You will see the dialog appear again in case the credentials you selected to be remembered are not valid. Providing them again allows you to change them.
I tried with proxy switch in the command itself.
Something like this and it worked for me:
node-gyp configure --proxy=http://proxy.server.name:port
Tried with this install nodejs package.
then open command prompt and enter npm commands.
set the proxy using below commands
npm set proxy http://name:password#gtpproxy.proxy.com:8080
npm set https-proxy http://name:password#gtpproxy.proxy.com:8080
npm config set strict-ssl false -g
Note:
Replace name with email
Replace password with the actual password
Replace gtpproxy with the proxy address of the location.
You will have to URL-encode your username and/or password. For example, if your username contains a domain, like e.g. DOMAIN\username, you'll have to URL-encode the backslash. Thus, you need to use DOMAIN%5Cusername. The same goes for your password, URL-encode each and every non-ascii character.
I am using Synergy Client in CentOs 7.
This is the problem that CentOs doesn't show mouse pointer when there is no mouse connected to the system.
Every time that I turn on my CentOs machine , I should connect the mouse to the machine otherwise CentOs doesn't show the mouse pointed for Synergy.
Everything is working with Synergy Client (click -right click , ...) but there is no mouse pointed!!!
How can I fix this problem? Synergy Client is running on CentOs 7 (64 bit)
Found the answer in this post: http://synergy-foss.org/osqa/questions/3148/ubuntu-1310-no-cursor-visable-with-synergyc
Fix:
Move the mouse to the system where the mouse pointer is not visible, open the terminal and paste the following command:
gsettings set org.gnome.settings-daemon.plugins.cursor active false
This should resolve the problem for the current session and future sessions.
I used the solution Michael Richmond presented.
Logging in, and with a terminal within that account executing
gsettings set org.gnome.settings-daemon.plugins.cursor active false
however I also wanted the mouse visible at the login window as well. I used this link to figure it out
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/customizing-login-screen
it says to create or edit the gdm profile at /etc/dconf/profile/gdm with the following contents
user-db:user
system-db:gdm
file-db:/usr/share/gdm/greeter-dconf-defaults
I then created a file /etc/dconf/db/gdm.d/01-Cursor
and put the following contents
[org/gnome/settings-daemon/plugins/cursor]
active=false
This essentially sets the same value in config file, but for the gdm login window.
After adding those files, I then executed dconf update to update the current running instance with the config setting.
At this point, I now have the synergy cursor available before and after login.
For some reason, all my LFS VM's defaulted to "USB Tablet" but CentOS VM's defaulted to "PS/2 Mouse". So my guess is the built-in templates (or whatever they are called) have that wrong. When creating a new VM, if I type in "LFS", I get Type "Linux" and Version "Linux 2.6/3.x (64-bit)" but if I type in "CentOS", I get Type "Linux" and Version "Red Hat (64 bit)". So, in my opinion, the "Red Hat (64 bit)" template should be changed to set Pointing Device to "USB Tablet".
some was unexpected at this time.
Guys. how do you configure easyphp to use chrome as the default browser. It keeps using ie when i use local web from the easyphp menu.
I have already tried to configure the apache but cant seem to find the browser option.
Any help would do. Hope someone can point me in the right direction.
It seems that easyPHP uses default system browser. I have Firefox as default so it uses Firefox. If you change default to Chrome it should also work. I don't see any browser setting in easyphp.ini so I believe you cannot change it if Chrome is not your default system browser.
I was looking for the options as well.
I couldn't find any, so I just created this piece of code.
Hope that helps.
Create a new text file with Notepad and name it like start-easyphp.bat
and save it inside the root directory of easyPHP (i.e C:\easyphp\start-easyphp.bat)
Note the file extension .bat
Paste this code inside the file you just created:
#echo off
echo Starting Server...
timeout 3 /nobreak >nul
start EasyPHP-DevServer-14.1VC9.exe
echo Starting a new session...
timeout 5 /nobreak >nul
start chrome http://127.0.0.1
Note: EasyPHP-DevServer-14.1VC9.exe should be replaced with the version you've installed on your machine.
If you use other browser like Firefox use start firefox http://127.0.0.1
For default browser you use start "" http://127.0.0.1
You can create shortcut on your desktop for quick access.
If you have multiple sites/project on the same local server, just targed
**127.0.0.1/my-projects/awesome-project**
Note: http://127.0.0.1 can also be http://localhost