I have a VueJS app hosted on Firebase, and I'm using CloudBuild to build and deploy it. My ultimate goal is to embed a version number or commit SHA into the footer of the front page, so we can always confirm which version we're seeing in the browser. Happy to hear alternate implementations, but right now I'm just trying to write a static text file.
I know each step in CloudBuild is a unique container, and only /workspace gets held over through each step. If I execute "pwd," I do see that's where all these steps take place.
I can even write the text file as shown (my date interpolation doesn't work), and see the file exists in the subsequent step. But after the final deployment, it's not there.
- name: gcr.io/cloud-builders/gcloud
entrypoint: /bin/bash
args: ['-c', "echo \"$REVISION_ID (commit $COMMIT_SHA) deployed on `date`\" >> ./static/version.txt"]
- name: 'bash'
args: ['ls', '-lart', './static']
# Deploy
- name: 'gcr.io/cloud-builders/npm:node-10.10.0'
args: ['run', 'deploy']
the ls output shows this:
total 56
drwxr-xr-x 2 root root 4096 Apr 17 20:52 svg
drwxr-xr-x 2 root root 4096 Apr 17 20:52 styles
drwxr-xr-x 2 root root 4096 Apr 17 20:52 plugins
-rw-r--r-- 1 root root 442 Apr 17 20:52 manifest.json
drwxr-xr-x 2 root root 4096 Apr 17 20:52 legal
drwxr-xr-x 2 root root 4096 Apr 17 20:52 js
drwxr-xr-x 4 root root 4096 Apr 17 20:52 images
drwxr-xr-x 2 root root 4096 Apr 17 20:52 gifs
drwxr-xr-x 3 root root 4096 Apr 17 20:52 fonts
-rw-r--r-- 1 root root 6148 Apr 17 20:52 .DS_Store
drwxr-xr-x 12 root root 4096 Apr 17 20:59 ..
-rw-r--r-- 1 root root 132 Apr 17 21:00 version.txt
drwxr-xr-x 10 root root 4096 Apr 17 21:00 .
So I know the version.txt file gets written and persists across steps.
The npm run deploy step just runs firebase deploy. The app deploys, but the version.txt file gives a 404. Notably, I can navigate to <APP_ROOT>/static/manifest.json and open that file in the browser -- but since it is part of the git revision, maybe that doesn't tell me much.
Not sure how to proceed from here. Am I missing something about how CloudBuild works? Is there a better way to do this version thing?
I have Artifactory 6.20.1 running in a Docker container. I'm trying to install the artifactCleanup plugin (https://github.com/jfrog/artifactory-user-plugins/tree/master/cleanup/artifactCleanup)
I have put the artifactCleanup.groovy file in the corresponding folder:
$ ls -all /opt/jfrog/artifactory/var/etc/artifactory/plugins/
total 36
drwxr-xr-x 2 artifact artifact 4096 Feb 24 10:28 .
drwxr-xr-x 3 artifact artifact 4096 Feb 23 15:24 ..
-rwxr-xr-x 1 artifact artifact 5829 Feb 23 15:25 README.md
-rwxr-xr-x 1 artifact artifact 14043 Feb 23 15:26 artifactCleanup.groovy
-rwxr-xr-x 1 artifact artifact 325 Feb 24 10:28 artifactCleanup.json
However if I'm trying to see my loaded plugins I get an empty response
curl -X GET -u "admin:password" http://localhost:8081/artifactory/api/plugins
{}
The Server has been restarted before running that request. All commands have been running inside the Docker container. I have been looking at the documentation (https://www.jfrog.com/confluence/display/JFROG/User+Plugins) on how to install plugins. My User account which was used for the rest calls is an admin account.
Now I am out of clues, why that plugin is not loading?
You can use the below reload plugins using the Reload Plugins REST API endpoint.
https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API#ArtifactoryRESTAPI-ReloadPlugins
Please comment here if you are running into any issues.
Turns out I created a wrong directory. Correct directory is
/var/opt/jfrog/artifactory/etc/plugins
which already existed.
I have a Synology Diskstation DS216se running DSM 6.2.3-25426. I've installed MariaDB 10, Web Station, PHP 7.2, and myPhpAdmin, but when I open it at http://diskstation/phpMyAdmin/ I get this error message
"Sorry, the page you are looking for is not found."
I'm using an nginx server in Web Station, and the error log at /var/log/nginx/error.log contains multiple entries like the following
*621 open() "/var/services/web/phpMyAdmin/js/vendor/jquery/jquery.debounce-1.0.5.js" failed (13: Permission denied)
The file, and all other files with permission denied entries in the logs, exist in the /var/services/web/phpMyAdmin/ directory - what permissions need to be granted to the directory for this to succeed?
I hit this as well. I managed to recover, but it effectively amounts to hard clearing any evidence of prior installs of Web Station, PHP 7.2, phpMyAdmin, and any other web related services. Then manually ripping out some bad directories with broken symlinks/permissions.
My hypothesis is that I tried to install adminer prior to this and - having not done any set up for Web Station et. al. - it put the filesystem in a bad state.
I am not willing to try installing adminer again to test this hypothesis.
What I did to fix this:
Backup what you need (e.g., any personal web site).
SSH into your diskstation. Please be aware of what you are doing and keep in mind the big picture. Don't go deleting random things.
Uninstall Web Station, PHP 7.2, Apache, phpMyAdmin, etc. Anything that Web Station would ultimately be inclined to read and serve up.
Verify that /var/services/web doesn't contain anything you care about, and delete it (sudo rm -rf /var/services/web).
Verify that /volume1/web doesn't contain anything you care about, and delete everything inside it (sudo rm -rf /var/services/web). You may need to chmod permissions for this - I ended up leaving the web directory itself intact, but nothing inside.
Reboot. Mount any encrypted disks, etc.
Check that /var/services/web now shows it is symlinked to /volume1/web, e.g. sudo readlink -e /var/services/web.
Also check permissions for /volume1/web, e.g. ls -al /volume1. It should be owned by root:root and have permissive (777) bits.
Install Web Station, PHP 7.2, and phpMyAdmin in that order.
After this, I could open phpMyAdmin and be served its log in screen.
Debugging notes:
For me, when I SSH in I see in the logs similar issues:
2020/12/17 10:36:35 [error] 32658#32658: *1028 "/var/services/web/phpMyAdmin/index.php" is forbidden (13: Permission denied),
ps says that the nginx workers run as the http user (uid=1023(http) gid=1023(http) groups=1023(http)).
The directory /var/services/web/ appears to be owned by root, both group and user:
# ls -al /var/services/web/
total 424
drwxr-xr-x 3 root root 4096 Dec 17 10:29 .
drwxr-xr-x 3 root root 4096 Dec 17 10:22 ..
-rw-r--r-- 1 root root 27959 Apr 13 2016 adminer.css
-rw-r--r-- 1 root root 82 Apr 13 2016 .htaccess
-rw-r--r-- 1 root root 387223 Apr 13 2016 index.php
drwxr-xr-x 10 root root 4096 Dec 17 10:29 phpMyAdmin
It's not clear to me how Web Station's nginx is intended to work at all given the mismatch - perhaps some set of actions I took prior caused it to decide to install with bad ownership.
I decided to leave everything owned by root, but changed group permissions so that http can access:
# chown -R root:http /var/services/web/
# chmod -R 775 /var/services/web/
This got past the initial error, but revealed a new one:
"/usr/syno/synoman/phpMyAdmin/index.cgi" is not found (2: No such file or directory)
Indeed, there was no trace of phpMyAdmin anywhere in that directory. Evidence of a bad install.
I decided to uninstall anything web related: phpMyAdmin, PHP 7, Apache (happened to be installed), nginx, and Web Station. Once I did, I still had two files in /var/services/web: adminer.css index.php.
I had tried adminer prior to this. In /var/services, there were symlinks to specific volume locations, e.g.:
# ls -al /var/services/
total 12
drwxr-xr-x 3 root root 4096 Dec 17 10:22 .
drwxr-xr-x 17 root root 4096 Dec 17 10:21 ..
lrwxrwxrwx 1 root root 18 Jan 20 2020 download -> /volume1/#download
lrwxrwxrwx+ 1 root root 14 Dec 17 10:22 homes -> /volume1/homes
lrwxrwxrwx 1 root root 24 Jan 20 2020 pgsql -> /volume1/#database/pgsql
lrwxrwxrwx 1 root root 13 Dec 17 10:22 tmp -> /volume1/#tmp
lrwxrwxrwx 1 root root 13 Dec 17 10:22 web
Interestingly, web was not symlinked. I fully deleted /var/services/web.
Looking over at /volume1, I do see a /volume1/web, again fully owned by root but with extremely constrained permission:
d---------+ 1 root root 52 Dec 17 10:14 web
There are only a few things in here, which look related to a blank install of Web Station. I fully deleted everything within /volume1/web, but left it as is. With everything maximally cleaned I rebooted.
Upon boot, /var/services/web was now symlinked to /volume1/web, which now also had useful permission bits (777), and owned by root:root. Maybe this was done by some boot recover process, who knows. (I still have nothing web related installed at this point.)
I installed Web Station, then PHP 7.2, then phpMyAdmin.
I had the same issue when accessing my server via
<name>.local/phpMyAdmin/
It worked when I accessed it via
<local ip>/phpMyAdmin/
I developed a C++ application that among others use SDL2.
It compiles and run on Ubuntu 18.04 (64 bit machine) and on OSX.
When I try to compile the application on a computer on chip running Ubuntu Mate 18.04 in a 32 bits machine with the libraries compiled by me, it returns an exception.
The exception is happening inside the line SDL_Init( SDL_INIT_VIDEO ) and the message is the following:
dbus[3856]: arguments to dbus_message_new_method_call were incorrect, assertion "path != NULL" failed in file ../../../dbus/dbus-message.c ine 1362.
This is normally a bug in some application using D-Bus library.
D-Bus not built with -rdynamic so unable to print backtrace.
Aborted
It seems a problem happening on Ubuntu running on a 32 bit machine. Have anyone had the same problem?
How can I solve this problem? Or does anyone know what is generating it?
NOTE 1
Running in gdb and using backtrace as suggested:
#0 0xb613d206 in __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1 0xb614ab32 in __libc_signal_restore_set (set=0xbeffe3a4) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
#2 0xb614ab32 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3 0xb614b82e in __GI_abort () at abort.c:79
#4 0xb2adddf0 in _dbus_abort () at /lib/arm-linux-gnueabihf/libdbus-1.so.3
#5 0xb2ad7c5a in _dbus_warn_check_failed () at /lib/arm-linux-gnueabihf/libdbus-1.so.3
#6 0xb2ad8104 in _dbus_warn_return_if_fail () at /lib/arm-linux-gnueabihf/libdbus-1.so.3
#7 0xb2acce80 in dbus_message_new_method_call () at /lib/arm-linux-gnueabihf/libdbus-1.so.3
#8 0xb68acdba in () at /usr/lib/arm-linux-gnueabihf/libSDL2-2.0.so.0
NOTE 2
The same happens if I install SDL from the repository instead of building it.
I found a partial solution so anybody with a better one would be welcome.
As #Keltar suggested in the comment I debugged it with gdb and backtrace as already said in the question. The last line of backtrace got me suspicious:
#8 0xb68acdba in () at /usr/lib/arm-linux-gnueabihf/libSDL2-2.0.so.0
which suggested it is not taking the library built by me but the one installed with apt. I checked all the paths in Makefile and everything was pointing to my custom built. So I checked the dynamic library files *.so and I found the situation was the following:
drwxr-xr-x 3 odroid odroid 4096 Oct 15 12:21 cmake
lrwxrwxrwx 1 odroid odroid 17 Oct 15 12:21 libSDL2-2.0d.so -> libSDL2-2.0d.so.0
lrwxrwxrwx 1 odroid odroid 21 Oct 15 12:21 libSDL2-2.0d.so.0 -> libSDL2-2.0d.so.0.8.0
-rw-r--r-- 1 odroid odroid 4317020 Oct 15 12:21 libSDL2-2.0d.so.0.8.0
lrwxrwxrwx 1 odroid odroid 15 Oct 15 12:40 libSDL2-2.0.so -> libSDL2-2.0d.so
-rw-r--r-- 1 odroid odroid 7593354 Oct 15 12:21 libSDL2d.a
-rw-r--r-- 1 odroid odroid 4754 Oct 15 12:19 libSDL2maind.a
lrwxrwxrwx 1 odroid odroid 14 Oct 15 13:38 libSDL2.so -> libSDL2-2.0.so
drwxr-xr-x 2 odroid odroid 4096 Oct 15 12:21 pkgconfig
Note that for the symbolic link file libSDL2.so -> libSDL2-2.0.so, the linked file libSDL2-2.0.so was not created.
My solution was to rebuild the library in Release mode instead of Debug using cmake -DCMAKE_BUILD_TYPE=Release: in that way all the files library are correct. Another solution might be to symlink the file(s) manually but is is easy to mess up something.
So it seems a bug in how SDL cmake write the instructions for the Debug build type because in release mode my program run.
If anyone has a better solution or find any error that I could not find please let me know.
I want to install groovy on a unix server and test functionality. I used manual instructions from the following link:
https://itekblog.com/centos-groovy-installation-tutorial-newbs-centos-6-x/
I think the java jdk is installed, but im not certain since I didnt do it myself. I base my opinion on the following commands(i edited output with xxxs to obfuscate info):
[root#xxx groovy]# which java
/opt/xxx/xxx/bin/java
and
[root#xxx bin]# ll
total 48
lrwxrwxrwx. 1 root jdk8 29 Aug 10 2017 jar ->
/opt/xxx/jdk8/current/bin/jar
lrwxrwxrwx. 1 root jdk8 30 Aug 10 2017 java ->
/opt/xxx/jdk8/current/bin/java
lrwxrwxrwx. 1 root jdk8 29 Aug 10 2017 jps ->
/opt/xxx/jdk8/current/bin/jps
lrwxrwxrwx. 1 root jdk8 32 Aug 10 2017 jstack ->
/opt/xxx/jdk8/current/bin/jstack
lrwxrwxrwx. 1 root jdk8 31 Aug 10 2017 jstat ->
/opt/xxx/jdk8/current/bin/jstat
lrwxrwxrwx. 1 root jdk8 33 Aug 10 2017 keytool ->
/opt/xxx/jdk8/current/bin/keytool
Here is my bash_profile:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
export GROOVY_HOME=/usr/groovy/groovy-2.5.1
PATH=$PATH:$HOME/bin:$GROOVY_HOME/bin
export PATH
I "reloaded" my profile:
source ~/.bash_profile
Here is what happens when I try to "run" groovy:
[root#lhost-cl2 groovy]# groovy -e 'println("Hello, World!")'
Exception in thread "main" java.lang.ClassFormatError:
org.codehaus.groovy.tools.GroovyStarter (unrecognized class file version)
at java.lang.VMClassLoader.defineClass(libgcj.so.10)
at java.lang.ClassLoader.defineClass(libgcj.so.10)
at java.security.SecureClassLoader.defineClass(libgcj.so.10)
at java.net.URLClassLoader.findClass(libgcj.so.10)
at java.lang.ClassLoader.loadClass(libgcj.so.10)
at java.lang.ClassLoader.loadClass(libgcj.so.10)
at gnu.java.lang.MainThread.run(libgcj.so.10)
Suggestions?
There were two versions of java installed on the server. The older version, not compatible with groovy, was being referenced. I updated the path and its happy now.