Sample 'hello' application from boxfuse does not work - cloudcaptain

Created the account, tried to run the sample 'hello' app.
$ boxfuse run hello-1.0.war
Boxfuse client v.1.8.6.659
Copyright 2015 Boxfuse GmbH. All rights reserved.
Account: xxx (xxx)
Downloading glibc 2.21 ...
Downloading busybox 1.22.1.01 ...
Downloading openjdk 8.60.22 ...
Downloading libgcc 4.9.2 ...
Downloading libpng 1.2.52 ...
Downloading zlib 1.2.8 ...
Downloading freetype 2.6 ...
Downloading ttf-bitstream-vera 1.10 ...
Downloading cacerts 2014.11.17 ...
Downloading tomcat 8.0.23 ...
Downloading linux 3.15.9 ...
Fusing Image for hello-1.0.war ...
ERROR: Both the http and the https ports are disabled. You must specify at least one for Tomcat to work.

Boxfuse 1.8.6 has an unfortunate regression that slipped through our tests. This has been fixed in 1.8.7. Simply update by issuing
boxfuse -u
and everything will work as expected.

Related

mysql_grants.present fails to execute with salt-stack

I'm new with saltstack, state file that i'm using:
mybd:
mysql_database.present
user22:
mysql_grants.present:
- grant: ALL PRIVILEGES
- database: 'mybd.*'
- user: user22
- host: localhost
- connection_user: root
- connection_host: localhost
- connection_pass: ''
- connection_unix_socket: /tmp/mysql.sock
- connection_charset: utf8
I am getting the following error when applying a mysql state:
ID: mybd
Function: mysql_database.present
Result: True
Comment: Database mybd is already present
Started: 09:05:09.366441
Duration: 5.835 ms
Changes:
ID: user22
Function: mysql_grants.present
Result: False
Comment: Failed to execute: "GRANT ALL PRIVILEGES ON mybd.* TO user22#localhost"
Started: 09:05:09.372849
Duration: 76.012 ms
Changes:
Summary for user
Succeeded: 1
Failed: 1
but when I go to mysql i notice that the privilege is added !
I don't know what I am doing wrong. Is there somebody who knows how to properly grant permissions to a user in mysql through salt-stack?
Salt Version:
Salt Version:
Salt: 2015.8.0
Dependency Versions:
Jinja2: 2.7.2
M2Crypto: 0.31.0
Mako: Not Installed
PyYAML: 3.11
PyZMQ: 15.3.0
Python: 2.7.5 (default, Nov 16 2020, 22:23:17)
RAET: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4
cffi: Not Installed
cherrypy: Not Installed
dateutil: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
libnacl: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.6.2
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
python-gnupg: Not Installed
smmap: Not Installed
timelib: Not Installed
System Versions:
dist: centos 7.9.2009 Core
machine: x86_64
release: 3.10.0-1160.15.2.el7.x86_64
system: CentOS Linux 7.9.2009 Core
mysql version:
mysql Ver 15.1 Distrib 10.3.31-MariaDB, for Linux (x86_64) using readline 5.1
To know the real answer you will have to look at the minions log file. If there are any errors listed that would be why the mysql.grant_add failed.
however the way the state works is it tries to determine if the grant is already there by using the mysql module to run mysql.grant_exists and look for the grant in the database. If it doesn't find it it will run the mysql.grant_add function.
mysql.grant_add will generate the query for the grant based on the information, run the query, if either of those processes fail it will report the failure in the minion log.
After that mysql.grant_add will run mysql.grant_exists to see if the grant was added. If that doesn't return properly it will report the failure. So the question is if mysql.grant_exists can see the grant.
Also with you being on such an old version of salt but a newer version of mysql it is possible that the grant table is not returning in a way that mysql.grant_exists can detect the grant. In which case it will detect as a failure and still be able to add.

OpenVAS: OSPD scanner can't be used as scanner in new task

After understanding how to add an ospd scanner, verify it etc ...
I though I could finally use it but got an error through UI to add it to a task.
In my case, I run OpenVAS 9 on a debian 9 and I'm trying to include a w3af scanner but I got the same issue with every OSP scanner I add.
my pip freeze :
ospd==1.2.0
ospd-debsecan==1.2b1
ospd-nmap==1.0b1
ospd-w3af==1.0.0
Note that here is an example of w3af but the issue is the same for debsecan scanner and nmap scanner.
my openvas-check-setup :
Step 1: Checking OpenVAS Scanner ...
OK: OpenVAS Scanner is present in version 5.1.1.
OK: redis-server is present in version v=3.2.6.
OK: scanner (kb_location setting) is configured properly using the redis-server socket: /tmp/redis.sock
OK: redis-server is running and listening on socket: /tmp/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: NVT collection in /usr/local/var/lib/openvas/plugins contains 47727 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
SUGGEST: Enable signature checking (see http://www.openvas.org/trusted-nvts.html).
OK: The NVT cache in /usr/local/var/cache/openvas contains 47727 files for 47727 NVTs.
Step 2: Checking OpenVAS Manager ...
OK: OpenVAS Manager is present in version 7.0.2.
OK: OpenVAS Manager database found in /usr/local/var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
OK: OpenVAS Manager database is at revision 184.
OK: OpenVAS Manager expects database at revision 184.
OK: Database schema is up to date.
OK: OpenVAS Manager database contains information about 47727 NVTs.
OK: At least one user exists.
OK: OpenVAS SCAP database found in /usr/local/var/lib/openvas/scap-data/scap.db.
OK: OpenVAS CERT database found in /usr/local/var/lib/openvas/cert-data/cert.db.
OK: xsltproc found.
Step 3: Checking user configuration ...
WARNING: Your password policy is empty.
SUGGEST: Edit the /usr/local/etc/openvas/pwpolicy.conf file to set a password policy.
Step 4: Checking Greenbone Security Assistant (GSA) ...
OK: Greenbone Security Assistant is present in version 7.0.2.
OK: Your OpenVAS certificate infrastructure passed validation.
Step 5: Checking OpenVAS CLI ...
OK: OpenVAS CLI version 1.4.5.
Step 6: Checking Greenbone Security Desktop (GSD) ...
SKIP: Skipping check for Greenbone Security Desktop.
Step 7: Checking if OpenVAS services are up and running ...
OK: netstat found, extended checks of the OpenVAS services enabled.
OK: OpenVAS Scanner is running and listening on a Unix domain socket.
OK: OpenVAS Manager is running and listening on a Unix domain socket.
OK: Greenbone Security Assistant is listening on port 443, which is the default port.
Step 8: Checking nmap installation ...
WARNING: Your version of nmap is not fully supported: 7.40
SUGGEST: You should install nmap 5.51 if you plan to use the nmap NSE NVTs.
Step 10: Checking presence of optional tools ...
OK: pdflatex found.
WARNING: PDF generation failed, most likely due to missing LaTeX packages. The PDF report format will not work.
SUGGEST: Install required LaTeX packages.
OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
OK: rpm found, LSC credential package generation for RPM based targets is likely to work.
OK: alien found, LSC credential package generation for DEB based targets is likely to work.
OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.
To create the scanner in openvas, I use:
openvasmd --create-scanner="w3af" --scanner-host=127.0.0.1 --scanner-port=1235 --scanner-type="OSP" \
--scanner-ca-pub=/usr/local/var/lib/openvas/CA/cacert.pem \
--scanner-key-pub=/usr/local/var/lib/openvas/CA/clientcert.pem \
--scanner-key-priv=/usr/local/var/lib/openvas/private/CA/clientkey.pem
To run ospd-w3af scanner, I use:
~# ospd-w3af -b 127.0.0.1 -p 1235 -k \
/usr/local/var/lib/openvas/private/CA/clientkey.pem -c \
/usr/local/var/lib/openvas/CA/clientcert.pem --ca-file \
/usr/local/var/lib/openvas/CA/cacert.pem -L DEBUG
When I verify the scanner with openvasmd --verify-scanner xxxxx I got
Scanner version: 2018.8.22.
note: in the logs of the scanner I got this for every verify I do, I don't know if it's related or no and I didn't find a way to fix this:
2018-10-15 14:27:47,413 ospd.ospd: DEBUG: New connection from 127.0.0.1:60078
2018-10-15 14:27:49,430 ospd.ospd: DEBUG: Error: ('The read operation timed out',)
2018-10-15 14:27:49,433 ospd.ospd: DEBUG: 127.0.0.1:60078: Connection closed
So, my verification made, I want to create a task that uses this scanner but I can't save it due to error "Given scanner_type was invalid" :
https://i.stack.imgur.com/fvIJd.png
I got 0 connection to the chosen scanner at this moment and I can't find anything in the logs (maybe I can't search). I suspect the gsad UI being responsible for this but I can't find it.
I don't know what to do and if someone more expert than me (not very hard) could help that'd be great :)
Thanks in advance.
I solved this issue by creating a scan configuration for the ospd scanner (I though it didn't need one since it import them)
I faced another issue concerning ospd-w3af configuration, I couldn't create one because it needs ospd 1.0.0 installed, I modified the dependencies few days ago and it doesn't work with ospd 1.2.0
Now I'm facing the issue where the scans doesn't start properly. It stops at 1%
Getting openvas 9 running on new install of Ubuntu 18 was a pain. once i got past all my errors by creating files and ln -s for redis-server socks connections my tasks crapped out at 1%. My fix was install sudo apt install libopenvas-dev after that scans work and check-setup worked. Check-setup report no scanner but openvassd was running and openvasmd --verify-scanner (uuid) showed the scanner.

Why is yum re-creating default nginx config file on yum update on RHEL7?

I installed nginx via yum package on RHEL7. I added my config as
/etc/nginx/conf.d/my.conf
and deleted the config file shipped with the package
/etc/nginx/conf.d/default.conf
Recently, nginx package was updated via yum update. Now, the default.conf file is present again. I would have expected that yum doesn't touch default config files if they were changed or deleted.
Is this normal yum behavior? Here some information about the RHEL version and nginx package.
root#host: [~]# yum info nginx
Loaded plugins: langpacks, product-id, rhnplugin, search-disabled-repos
This system is receiving updates from RHN Classic or Red Hat Satellite.
Installed Packages
Name : nginx
Arch : x86_64
Epoch : 1
Version : 1.14.1
Release : 1.el7_4.ngx
Size : 2.6 M
Repo : installed
From repo : nginx
Summary : High performance web server
URL : http://nginx.org/
License : 2-clause BSD-like license
Description : nginx [engine x] is an HTTP and reverse proxy server, as well as
: a mail proxy server.
I upgrade the package from 1.14.0 to version 1.14.1 shown above.
root#host: [~]# nginx -v
nginx version: nginx/1.14.1
Redhat version:
root#host: [~]# hostnamectl
Static hostname: host.example.com
Icon name: computer-vm
Chassis: vm
Machine ID: SOME-ID
Boot ID: ANOTHER-ID
Virtualization: vmware
Operating System: Red Hat Enterprise Linux
CPE OS Name: cpe:/o:redhat:enterprise_linux:7.5:GA:server
Kernel: Linux 3.10.0-862.14.4.el7.x86_64
Architecture: x86-64
If I rename my.conf to default.conf, it doesn't get replaced on a yum update.

You must be online once before you can use Boxfuse offline

I'm following the boxfuse tutorial.
Everything seems to we working...
$ boxfuse -v
Boxfuse client v.1.23.0.1181
Copyright 2016 Boxfuse GmbH. All rights reserved.
VirtualBox : 5.0.26r108824
JVM : 1.8.0_74 (Oracle Corporation)
Host IP : 10.0.1.10 (24:a5:68:2d:5a:a1)
OS : Mac OS X 10.11.6 x86_64
So I generate and attempt to run their sample app...
$ boxfuse run hello-1.0.war
Boxfuse client v.1.23.0.1181
Copyright 2016 Boxfuse GmbH. All rights reserved.
ERROR: You must be online once before you can use Boxfuse offline. Go online and try again
As you can see, the app failed. I've no context to understand what is meant by online/offline in this error message.
What do I need to do?
That message indicates that there was some kind of connectivity issue between the machine where you ran the Boxfuse Client on and the Boxfuse Console.
Ensure internet connectivity is working and retry. Everything should then work as expected.

Gitlab on an OpenVZ Server with nginx - Authentication Required popup

I am experiencing an issue where trying to access GitLab through my browser is providing me with a popup for Authentication. It looks like a .htaccess authentication popup, but I have not configured htaccess authentication with my nginx configuration.
Authentication Required
The server at http://git.servername.com:80 requires a username and password.
The server says: Password Protected.
Username:
Password:
I have tried troubleshooting this issue for a couple of days now, but I am running into some dead ends, since I see no information in my nginx error logs, or my GitLab production.log.
I recently performed an installation of GitLab on Ubuntu 12.04 (following this guide: https://www.digitalocean.com/community/articles/how-to-set-up-gitlab-as-your-very-own-private-github-clone), and ran into some issues with not having enough memory on OpenVZ. I created some fake swap to get over this hurdle, and I have verified that the GitLab server is running. My verification and configuration information is as follows:
GitLab Verification
user#server:/home/git/gitlab$ sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
Checking Environment ...
Git configured for git user? ... yes
Has python2? ... yes
python2 is supported version? ... yes
Checking Environment ... Finished
Checking GitLab Shell ...
GitLab Shell version >= 1.7.0 ? ... OK (1.7.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by git:git? ... yes
Repo base access is drwxrws---? ... yes
post-receive hook up-to-date? ... yes
post-receive hooks in repos are links: ... can't check, you have no projects
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Checking Sidekiq ... Finished
Checking GitLab ...
Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
Projects have satellites? ... can't check, you have no projects
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.9.1)
Checking GitLab ... Finished
Environment Info
user#server:/home/git/gitlab$ sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
System information
System: Ubuntu 12.04
Current User: git
Using RVM: no
Ruby Version: 2.0.0p247
Gem Version: 2.0.3
Bundler Version:1.6.0
Rake Version: 10.1.0
GitLab information
Version: 6.0.2
Revision: 10b0b8f
Directory: /home/git/gitlab
DB Adapter: mysql2
URL: http://git.servername.com
HTTP Clone URL: http://git.servername.com/some-project.git
SSH Clone URL: git#git.servername.com:some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 1.7.0
Repositories: /home/git/repositories/
Hooks: /home/git/gitlab-shell/hooks/
Git: /usr/bin/git
Nginx Configuration
In my default.conf file:
server {
listen 80;
server_name git.servername.com;
location / {
proxy_pass http://git.servername.com:80;
}
}
Hosts file on my personal machine (not my VPS)
<IP Address of VPS> git.servername.com

Resources