I'm trying to get snowsql working locally on my machine but I cannot log into my database because it requires that I authenticate with my google account for SSO. The documentation says to use the --authenticator externalbrowser option which should open a local browser and ask me to sign on but that doesn't happen, nothing happens.
Example:
$ snowsql -o log_level=DEBUG -a <account> -u <gmail> --authenticator externalbrowser
Initiating login request with your identity provider. A browser window should have opened for you to complete the login. If you can't see it, check existing browser windows, or your OS settings. Press CTRL+C to abort and try again...
No browser windows open. Pressing CTRL+C does not abort snowsql; I must run pkill to kill it. The last of my logs show
2021-06-17 14:48:12,211 (222954/MainThread) snowflake.connector.network DEBUG network:940 - SUCCESS
2021-06-17 14:48:12,212 (222954/MainThread) snowflake.connector.network DEBUG network:1096 - Active requests sessions: 0, idle: 1
2021-06-17 14:48:12,212 (222954/MainThread) snowflake.connector.network DEBUG network:642 - ret[code] = None, after post request
2021-06-17 14:48:12,212 (222954/MainThread) snowflake.connector.auth_webbrowser DEBUG auth_webbrowser:123 - step 2: open a browser
2021-06-17 14:48:12,237 (222954/MainThread) snowflake.connector.auth_webbrowser DEBUG auth_webbrowser:136 - step 3: accept SAML token
platform:
Platform is Arch Linux (kernel version 5.12.10)
Default browser is BROWSER=/usr/bin/firefox
snowsql --version says 1.2.15
Installed via snowflake-client AUR package. (Which currently says version 1.2.14 but I believe snowsql updated itself to 1.2.15.)
See this answer for why snowsql isn't working. tl;dr it bundles it's own version of libz and doesn't use the system's version when opening your browser.
Based on that answer I concocted a little script to replace the bundled libz with the system libz. You'll need to run it whenever snowflake updates.
#!/usr/bin/env bash
VERSION=$(snowsql --version | cut -d' ' -f2)
LIBS="$HOME/.snowsql/$VERSION"
LIBZ="$LIBS/libz.so.1"
if ! [[ -L $LIBZ ]]
then
mv -v $LIBZ{,-bak}
fi
SYSTEM=$(sudo find /usr -name libz.so* 2> /dev/null | head -n1)
ln -sfv $SYSTEM $LIBZ
for me, setting the --region flag solved it, even though it's deprecated, according to the official documentation
Related
I have installed and configured and also used TV the first time today in Nvidia jetson Xavier,
but after restart Im getting this issue:
teamviewerd.service: Can't open PID file /var/run/teamviewerd.pid (yet?) after start: No such file or directory
Please tell me why and how to fix it, it is of extreme importance !
I use TeamViewer to connect to a machine (Ubuntu 20.04) that not always have a graphical user session started and I noticed that even with teamviewerd running the machine is offline.
I fixed the problem running:
sudo teamviewer setup
From teamviewer --help:
teamviewer setup Configure headless modes (non-gui/console)
Without running this, the only way for me was to start manually a graphical user session and open the TeamViewer GUI on the host I wanted to use.
Make sure you enable/start gdm.service or another supported login manager
Found this question via a search when facing the same issue on Fedora 30 x86_64.
Solution for me was to edit /etc/systemd/system/teamviewerd.service and comment out the line that says:
PIDFile = /run/teamviewerd.pid
So it reads:
# PIDFile = /run/teamviewerd.pid
(or whatever PIDFile it specifies)
then run:
systemctl daemon-reload
systemctl start teamviewerd
systemctl status teamviewerd
I am not able to install the package odl-dlux-all on the Ubuntu 16.04 machine. Following is the error message
Error executing command: Can't install feature odl-dlux-all/0.0.0:
null
VM : Ubuntu 16.04
Opendaylight version : Carbon
What is the issue?
Should i install gnome-desktop for this?
Prat,
This is what I have found. It looks like you and I were in the same boat. I ran into this issue, also. After additional searching, I found that ODL's website has a guide for the DLUX features.
These are the features I installed and it got me where I needed:
odl-dlux-core
odl-dluxapps-nodes
odl-dluxapps-topology
odl-dluxapps-yangui
odl-dluxapps-yangvisualizer
odl-dluxapps-yangman
Be sure you enter them as separate commands using the feature:install command prior to each of them.
I found the guide on ODL's website HERE.
I hope this helps!! :)
The way OpenDaylight's DLUX features are structured was changed in Carbon. Application-specific logic was broken out into odl-dluxapps-* Karaf features for easier maintenance.
Install and start OpenDaylight:
sudo dnf install -y http://cbs.centos.org/repos/nfv7-opendaylight-70-release/x86_64/os/Packages/opendaylight-7.0.0-1.el7.noarch.rpm
sudo systemctl start opendaylight
Connect to the Karaf shell (make take a moment for Karaf's SSH server to come up):
ssh -p 8101 karaf#localhost
# password: karaf
See the available DLUX features:
opendaylight-user#root>feature:list | grep dluxapps
odl-dluxapps-yangutils
odl-dluxapps-yangui
odl-dluxapps-topology
odl-dluxapps-yangvisualizer
odl-dluxapps-applications
odl-dluxapps-yangman
odl-dluxapps-nodes
features-dluxapps
Install the ones you're interested in:
opendaylight-user#root>feature:install odl-dluxapps-topology
In a browser on the same machine:
http://localhost:8181/index.html#/yangui/index
Login with admin/admin and things should work.
Here are the DLUX docs.
Note that DLUX isn't widely used by ODL developers, and isn't packaged as a product by vendors. Most people use the REST API directly to query OpenDaylight. There are REST API examples in the NetVirt Postman Collection, as an example.
It is true. You have to install all dlux features manually.
The Change against ODL Boron is, that Carbon removed feature odl-dlux-all. And in Carbon odl-dlux-core installs only core and nothing more. I had always gray login page in DLUX WEB login, there was nothing, only blank gray page.
I suggest you to use command: feature:list | grep dlux
This will create for you complete list of available DLUX features. And You have to install all of them.
After you finish installation of DLUX use same command with parameter -i which will show you only succesfully installed features:
feature:list -i | grep dlux
so you will see the result.
Don't forget that after instalation Dlux needs a few minutes to be fully ready. If you try to login to dlux during this time, you can get ERROR403 but also login page will not accept the credentials even they are correct. So be patient and wait.
+----------------------------------------------------------------------+
DOCUMENTATION OF OPENDAYLIGHT
IS HORIBBLE AND SOMETIMES PURELY WRONG
+----------------------------------------------------------------------+
I am using 5 cloud-based VMs to install DC/OS
1 mesos master
3 mesos agent
1 launching VM
I have installed Docker on my launching VM and start installing DC/OS. It is running successfully during install_prereqs stage without any errors. But it's failing during preflight with below errors for each of my VM system.
STDERR:
Connection to 129.114.18.235 closed.
STDOUT:
Running preflight checks /opt/dcos_install_tmp/dcos_install.sh: line 225: getenforce: command not found
Checking if docker is installed and in PATH: FAIL
Checking if unzip is installed and in PATH: FAIL
Checking if ipset is installed and in PATH: FAIL
Checking if systemd-notify is installed and in PATH: FAIL
/opt/dcos_install_tmp/dcos_install.sh: line 387: systemctl: command not found
Checking if systemctl is installed and in PATH: FAIL
Checking Docker is configured with a production storage driver: /opt/dcos_install_tmp/dcos_install.sh: line 285: docker: command not found
Do I need to install all the required software into my master and agents VMS? Please guide.
We have a similar setup but using straight vm's. We found docker needs to be running on all nodes, including masters, before running the install. Also, make sure you look at: /etc/sysconfig/docker-storageand have: DOCKER_STORAGE_OPTIONS= -s overlayset in the file on all nodes.
I don't believe this is the production setup but should get you running. You also may want to check the privilege of the user executing the install on the remote nodes, does it have permission to see/run systemctl?
I had the same error with the DC/OS web installer in version 1.9
I solved the error after double-checking the bootstraps machines's private key in the web form. To create the key, log into the bootstrap machine and run:
$ ssh-keygen -t rsa
$ for i in `cat dcos-ips.txt`; do ssh-copy-id root#$i; done
$ cat ~/.ssh/id_rsa
I've set up an App Engine project locally using Docker (on OSX), and have been running a server using the usual "gcloud preview app run app.yaml" command. From what I can tell, this keeps creating new images over and over again. After an hour or so of work I end up with something like 30 docker images, each taking 130MB.
Eventually I'm told I can no longer bind to localhost:8080. I tried killing all containers and images, but still cannot use localhost:8080 until I reboot.
Seems like I'm not using Docker/gcloud correctly. Anyone have an idea what I might be doing wrong? Is there another way I should be restarting App Engine instances other than hitting command C and running the "run" command again?
UPDATE: After looking closer, I noticed I'm getting this message when I run an app locally and a container is created: "http: Hijack is incompatible with use of CloseNotifier". I'm not familiar enough with Docker to understand what's going on here. All searches seem to point to Go, which I am not using.
UPDATE 2: Here is the trace:
Creating container...
INFO 2015-05-05 02:23:28,293 containers.py:560] Container 1564ce4344957114312d6d1dc696ffbb4176b40ace6dcff5e4239e13ee04a8f6 created.
Exception in thread Thread-2:
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "/Users/judeosborn/google-cloud-sdk/platform/google_appengine/google/appengine/tools/docker/containers.py", line 643, in _ListenToLogs
for line in log_lines:
File "/Users/judeosborn/google-cloud-sdk/./lib/docker/docker/client.py", line 225, in _multiplexed_response_stream_helper
socket = self._get_raw_response_socket(response)
File "/Users/judeosborn/google-cloud-sdk/./lib/docker/docker/client.py", line 167, in _get_raw_response_socket
self._raise_for_status(response)
File "/Users/judeosborn/google-cloud-sdk/./lib/docker/docker/client.py", line 119, in _raise_for_status
raise errors.APIError(e, response, explanation=explanation)
APIError: 500 Server Error: Internal Server Error ("http: Hijack is incompatible with use of CloseNotifier")
INFO 2015-05-05 02:23:28,606 module.py:1745] New instance for module "default" serving on:
http://localhost:8080
There's an ongoing issue with Docker 1.6.x [reference] that prevents gcloud to work well with Managed VMs (as you seem to be using). Easiest workaround until it gets fixed is to downgrade Docker in your development machine to version 1.5.0, which is the latest version known to work.
For Ubuntu, you can do something like:
$ curl -sSL https://get.docker.com/ubuntu | sed 's/lxc-docker/lxc-docker-1.5.0/' | sudo sh
For other Linux distros, you might have to modify that sed pattern, though.
On the other hand, if you're using Boot2Docker under Mac OS X, follow these steps:
Fully uninstall your previous Boot2Docker/Docker setup; there is a nice guide here
Reinstall Boot2Docker/Docker following instructions here. IMPORTANT: You MUST stop right after completing "Install Boot2Docker" step and before "Start the Boot2Docker Application". Once you get there, open up a terminal and execute the following commands:
$ mkdir ~/.boot2docker
$ echo 'ISOURL="https://github.com/boot2docker/boot2docker/releases/download/v1.5.0/boot2docker.iso"' > ~/.boot2docker/profile
At this point, you can continue with "Start the Boot2Docker Application" section and finish the installation. You should now have a valid Docker launchpad with which to start Managed VMs. It'd be nice to double check that you have the right versions installed by issuing:
$ boot2docker ssh docker version | egrep "(Client|Server) version"
The output should look like:
Client version: 1.5.0
Server version: 1.5.0
Now you can try again your original command:
$ gcloud preview app run app.yaml
Try running:
$ ps uax | egrep "gcloud|appserver"
If you see anything running, kill it... you may even need to kill -9 it.
I have my Eclipse Kepler and my simple HelloWorld C-program, where I wanted to learn how to debug a C-program. When clicking on the debug-button, I get the following error message:
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Unable to find Mach task port for process-id 359: (os/kern) failure (0x5).
Unable to find Mach task port for process-id 359: (os/kern) failure (0x5).
I searched the whole day and didn't find any solution. I already did all of the recommended things in this post Eclipse GDB MacOSX Mavericks and still get this error.
It would be really great, if somebody could help me out setting up the debugger in Eclipse.
Oh and I downloaded and installed gdb-apple via macports and I had to use the "-f" option with the codesign command as it didn't work without. Maybe these are important information.
Keep using gdb (not gdb-apple) and just do the following steps:
1- Create a certificate:
Start Keychain Access application (/Applications/Utilities/Keychain Access.app)
Open menu /Keychain Access/Certificate Assistant/Create a Certificate...
Choose a name (gdb-cert in the example), set Identity Type to "Self Signed Root", set Certificate Type to "Code Signing" and select the "Let me override defaults".
Click several times on Continue until you get to the Specify a Location For The Certificate screen, then set Keychain to System.
Using the contextual menu for the certificate, select "Get Info", open the Trust item, and set Code Signing to "Always Trust".
2- You must quit Keychain Access application (named "taskgated",from activity monitor) and open it again in order to use the certificate.
3- Assign the certificate to gdb:
using the following command: $ codesign -s gdb-cert gdb
For more details, check this link:
http://sourceware.org/gdb/wiki/BuildingOnDarwin
if any of these steps are not clear, feel free to ask.
This may happen if you signed 'gdb' before making all changes to 'gdb-cert'. Then you can restart 'taskgated' and then re-sign the 'gdb' executable.
ps -e | grep taskgated
sudo kill -9 <pid of taskgated>
codesign -f -s gdb-cert $(which gdb)
This worked for me.
If you get this below error, don't forget to add sudo in front of the command:
sudo codesign -s gdb-cert $(which gdb-apple)
codesign -s gdb-cert $(which gdb-apple)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: can't create output file: /opt/local/bin/gdb-apple.cstemp (Permission denied)
/opt/local/bin/gdb-apple: the codesign_allocate helper tool cannot be found or used