I installed the Go app engine packages this evening. This seems to have broken my whole Go installation.
Each time I attempt to run any go command, it fails with:
../../../google.golang.org/grpc/credentials/oauth/oauth.go:85: undefined: google.JWTAccessTokenSourceFromJSON
Erm...
I tried nuking the google.golang.org directory without success. When I run go get -x ./... I get the following:
WORK=/var/folders/94/4lkprvq57vj4svwmt_kz5h6m0000gn/T/go-build842729114
mkdir -p $WORK/google.golang.org/grpc/credentials/oauth/_obj/
mkdir -p $WORK/google.golang.org/grpc/credentials/
cd /Users/simon/Documents/Code/golang/src/google.golang.org/grpc/credentials/oauth
/usr/local/Cellar/go/1.6.2/libexec/pkg/tool/darwin_amd64/compile -o $WORK/google.golang.org/grpc/credentials/oauth.a -trimpath $WORK -p google.golang.org/grpc/credentials/oauth -complete -buildid 8d03dba436005dd3d1e75147bde330259f288075 -D _/Users/simon/Documents/Code/golang/src/google.golang.org/grpc/credentials/oauth -I $WORK -I /Users/simon/Documents/Code/golang/pkg/darwin_amd64 -pack ./oauth.go
# google.golang.org/grpc/credentials/oauth
../../../google.golang.org/grpc/credentials/oauth/oauth.go:85: undefined: google.JWTAccessTokenSourceFromJSON
Help needed fixing before all sanity gone.
I ran into this problem as well. I think the go get functionality pulled an outdated repo when updating the Google app engine packages.
This worked for me:
cd $GOPATH/src/golang.org/x/oauth2/google
git fetch
git pull
Turns out I was 66 commits behind master; this fixed it for me. Hope it works for you.
Related
On a completely fresh ubuntu 18.04 VM I tried to install opam:
$ wget https://github.com/ocaml/opam/releases/download/2.1.0/opam-2.1.0-x86_64-linux
$ mv opam-2.1.0-x86_64-linux opam
$ chmod 777 opam
$ ./opam init
And here is the error I got
<><> Fetching repository information ><><><><><><><><><><><><><><><><><><><><><>
[ERROR] Could not update repository "default": OpamDownload.Download_fail(_,
"Download command failed: \"/usr/bin/wget --content-disposition -t 3 -O
/tmp/opam-5936-f23d09/index.tar.gz.part -U opam/2.1.0 --
https://opam.ocaml.org/index.tar.gz\" exited with code 5 \"ERROR:
cannot verify opam.ocaml.org's certificate, issued by
\226\128\152CN=Zscaler Intermediate Root CA (zscaler.net) (t)\\\\
,OU=Zscaler Inc.,O=Zscaler Inc.,ST=California,C=US\226\128\153:\"")
[ERROR] Initial download of repository failed.
How should I solve this?
I ran into the same issue and I found a workaround on the OCaml forum: here. (Credits to UnixJunkie)
You can run:
opam init github git+https://github.com/ocaml/opam-repository.git
This should avoid the certificate issues. This worked for me.
I tried to fix the certificate issues using this answer as well. You could try doing that, but it seems complicated when the workaround is to simply point it to the github repo directly.
Update
The reason opam init failed for me was because curl was installed with snap on my system.
Try to run opam init -verbose and that could reveal more about why you ran into an error.
In my case I needed to install other things with opam and it kept failing every time. So snap uninstall curl and then sudo apt install curl fixed things. (Was only able to figure this out with the help from my professor)
I am new in elasticsearch. I have to set up wazuh with elasticsearch cluster. I did all the thing. I have also installed wazuh plugin on the Kibana . Once, I opened the app and clicked on the agent section It is saying =>
Error getting alerts from compliances
Your environment may not have any index with Wazuh's alerts
Please help me.
you could try to uninstall and install it again. Here you have the official uninstallation guide Uninstalling Wazuh with Elastic Stack, and after installing Elastic again with this guide Unattended installation
Remember if you want to preserve your configuration you can backup the files:
cp -p /var/ossec/etc/ossec.conf.orig /var/ossec_backup/etc/ossec.conf
cp -p /var/ossec/etc/local_internal_options.conf /var/ossec_backup /etc/local_internal_options.conf
cp -p /var/ossec/etc/ /var/ossec_backup/etc/client.keys
cp -p /var/ossec/queue/rids/ /var/ossec_backup/queue/rids/*
Here you have more information about that Migrating OSSEC agent
After that, you have to put the files in their original path again
I am trying to mount a GCS bucket on AppEngine Flexible Environment app using gcsfuse.
My Dockerfiles includes the following:
# gscfuse setup
RUN echo "deb http://packages.cloud.google.com/apt cloud-sdk-jessie main" | tee /etc/apt/sources.list.d/google-cloud.sdk.list
RUN echo "deb http://packages.cloud.google.com/apt gcsfuse-jessie main" | tee /etc/apt/sources.list.d/gcsfuse.list
RUN wget -qO- https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
RUN apt-get update && apt-get install -y --no-install-recommends google-cloud-sdk gcsfuse strace
RUN gcsfuse --implicit-dirs my_bucket my_dir
I took most of this from here. It's pretty much just the standard way to install gcsfuse, plus --no-install-recommends.
If I start an app this way, it does not mount the drive. This was not too surprising to me, since it didn't seem like a supported feature of the flexible environment.
Here is the confusing part. If I run gcloud app instances ssh "<instance>", then run container_exec gaeapp /bin/bash, then gcsfuse my_bucket my_dir works fine.
However, if I run gcloud app instances ssh "<instance>" --container gaeapp, then gcsfuse my_bucket my_dir fails with this error:
fusermount: failed to open /dev/fuse: Operation not permitted
This is the same error I get if I run gcsfuse as a subprocess in my main.py.
Based on this unresolved thread, I ran strace -f and saw the exact same problem as that user did, an EPERM issue.
[pid 59] open("/dev/fuse", O_RDWR) = -1 EPERM (Operation not permitted)
Whichever way I log into the container (or if I run a subprocess from main.py), I am user root. If I run export then I do see different vars, so there is some difference in what's being run, but everything else looks the same to me.
Other suggestions I've seen include using the gcsfuse flags -o allow_other and -o allow_root. These did not work.
There may be a clue in the fact that if I try to run umount on a login that cannot run gcsfuse, it says "must be superuser to unmount", even though I am root.
It seems like there is probably some security setting that I do not understand. However, since I could in theory get main.py to trigger an external program to log in and run gcsfuse for me, it seems like there should be a way to get it to work without having to do that.
RUN commands are about creating a new layer for your dockerfile, so you're actually running that command during the image creation, which the Flex build system doesn't like.
I'm not sure why shelling out in the application didn't work, you could try 'sudo'ing it in the python subprocess, or possibly push it out of the application code by adding 'gcsfuse setup &&' to the ENTRYPOINT in the dockerfile.
I have now managed to deploy a web app on run#cloud. I do have the cloudbees deployer plugin on jenkins, however, i am looking for a way to use the bees sdk to bind a database to the deployed app. I was wondering how do i go about it.
Currently, I deploy it via jenkins as a postbuild action.
You can configure the Bees SDK in DEV#cloud with a script like this (assuming that you have uploaded a build secret zip file containing your ~/.bees/bees.config using the environment variable ${SECRET} - please see Build Secret Plugin
Run this as an "Execute Shell" task within Jenkins, and then you can use the Bees SDK in the normal way to bind the database (or any resource) to your app, e.g.
bees app:bind -a acme/test -db mydb
See the Database Guide for more details.
Jenkins Execute Shell Script:
if [[ ! -d "${WORKSPACE}/bees-sdks" ]]
then
mkdir ${WORKSPACE}/bees-sdks
fi
cd ${WORKSPACE}/bees-sdks;
curl -o cloudbees-sdk-1.5.0-bin.zip http://cloudbees-downloads.s3.amazonaws.com/sdk/cloudbees-sdk-1.5.0-bin.zip;
unzip -o cloudbees-sdk-1.5.0-bin.zip
rm cloudbees-sdk-1.5.0-bin.zip
PATH=${WORKSPACE}/bees-sdks/cloudbees-sdk-1.5.0:$PATH; export PATH
if [[ ! -d ~/.bees ]]
then
mkdir ~/.bees
fi
cp ${SECRET}/bees.config ~/.bees/bees.config
I've done an online example here that illustrates how this all works. Sorry this is a little more complicated than we would like: we are working to make it smoother and I will update this answer shortly once the changes go live.
I have made a .deb of my app using fpm:
fpm -s dir -t deb -n myapp -v 9 -a all -x "*.git" -x "*.bak" -x "*.orig" \
--after-remove debian/postrm --after-install debian/postinst \
--description "Automated build." -d mysql-client -d python-virtualenv home
Among other things, the postinst script is supposed to create a user for the app:
#!/bin/sh
set -e
APP_NAME=myapp
case "$1" in
configure)
virtualenv /home/$APP_NAME/local
#supervisorctl start $APP_NAME
;;
# http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-bpp-lower-privs
install|upgrade)
# If the package has default file it could be sourced, so that
# the local admin can overwrite the defaults
[ -f "/etc/default/$APP_NAME" ] && . /etc/default/$APP_NAME
# Sane defaults:
[ -z "$SERVER_HOME" ] && SERVER_HOME=/home/$APP_NAME
[ -z "$SERVER_USER" ] && SERVER_USER=$APP_NAME
[ -z "$SERVER_NAME" ] && SERVER_NAME=""
[ -z "$SERVER_GROUP" ] && SERVER_GROUP=$APP_NAME
# Groups that the user will be added to, if undefined, then none.
ADDGROUP=""
# create user to avoid running server as root
# 1. create group if not existing
if ! getent group | grep -q "^$SERVER_GROUP:" ; then
echo -n "Adding group $SERVER_GROUP.."
addgroup --quiet --system $SERVER_GROUP 2>/dev/null ||true
echo "..done"
fi
# 2. create homedir if not existing
test -d $SERVER_HOME || mkdir $SERVER_HOME
# 3. create user if not existing
if ! getent passwd | grep -q "^$SERVER_USER:"; then
echo -n "Adding system user $SERVER_USER.."
adduser --quiet \
--system \
--ingroup $SERVER_GROUP \
--no-create-home \
--disabled-password \
$SERVER_USER 2>/dev/null || true
echo "..done"
fi
# … and a bunch of other stuff.
It seems like the postinst script is being called with configure, but not with install, and I am trying to understand why. In /var/log/dpkg.log, I see the lines I would expect:
2012-06-30 13:28:36 configure myapp 9 9
2012-06-30 13:28:36 status unpacked myapp 9
2012-06-30 13:28:36 status half-configured myapp 9
2012-06-30 13:28:43 status installed myapp 9
I checked that /etc/default/myapp does not exist. The file /var/lib/dpkg/info/myapp.postinst exists, and if I run it manually with install as the first parameter, it works as expected.
Why is the postinst script not being run with install? What can I do to debug this further?
I think the example script you copied is simply wrong. postinst is not
supposed to be called with any install or upgrade argument, ever.
The authoritative definition of the dpkg format is the Debian Policy
Manual. The current version describes postinst in chapter
6
and only lists configure, abort-upgrade, abort-remove,
abort-remove, and abort-deconfigure as possible first arguments.
I don't have complete confidence in my answer, because your bad example
is still up on debian.org and it's hard to believe such a bug could slip
through.
I believe the answer provided by Alan Curry is incorrect, at least as of 2015 and beyond.
There must be some fault with the way the that your package is built or an error in the postinst file which is causing your problem.
You can debug your install by adding the -D (debug) option to your command line i.e.:
sudo dpkg -D2 -i yourpackage_name_1.0.0_all.deb
-D2 should sort out this type of issue
for the record the debug levels are as follows:
Number Description
1 Generally helpful progress information
2 Invocation and status of maintainer scripts
10 Output for each file processed
100 Lots of output for each file processed
20 Output for each configuration file
200 Lots of output for each configuration file
40 Dependencies and conflicts
400 Lots of dependencies/conflicts output
10000 Trigger activation and processing
20000 Lots of output regarding triggers
40000 Silly amounts of output regarding triggers
1000 Lots of drivel about e.g. the dpkg/info dir
2000 Insane amounts of drivel
The install command calls the configure option and in my experience the postinst script will always be run. One thing that may trip you up is that the postrm script of the "old" version, if upgrading a package, will be run after your current packages preinst script, this can cause havoc if you don't realise what is going on.
From the dpkg man page:
Installation consists of the following steps:
1. Extract the control files of the new package.
2. If another version of the same package was installed before
the new installation, execute prerm script of the old package.
3. Run preinst script, if provided by the package.
4. Unpack the new files, and at the same time back up the old
files, so that if something goes wrong, they can be restored.
5. If another version of the same package was installed before
the new installation, execute the postrm script of the old pack‐
age. Note that this script is executed after the preinst script
of the new package, because new files are written at the same
time old files are removed.
6. Configure the package.
Configuring consists of the following steps:
1. Unpack the conffiles, and at the same time back up the old
conffiles, so that they can be restored if something goes wrong.
2. Run postinst script, if provided by the package.
This is an old issue that has been resolved, but it seems to me that the accepted solution is not totally correct and I believe that it is necessary to provide information for those who, like me, are having this same problem.
Chapter 6.5 details all the parameters with which the preinst and postinst files are called
At https://wiki.debian.org/MaintainerScripts the installation and uninstallation flow is detailed.
Watch what happens in the following case:
apt-get install package
- It runs preinst install and then postinst configure
apt-get remove package
- Execute postrm remove and the package will be set to "Config Files"
For the package to actually be in the "not installed" state it must be used:
apt-get purge package
That's the only way we'll be able to run preinst install and postinst configure the next time the package is installed.