search

snipe / snipe-it

A free open source IT asset/license management system
https://snipeitapp.com
GNU Affero General Public License v3.0
11.12k stars 3.19k forks source link

Moved servers and now LDAP won't enable #10747

Closed Christopheric1 closed 2 years ago

Christopheric1 commented 2 years ago

Debug mode

Describe the bug

I am getting an issue with LDAP where I changed servers from CentOS 7 to Debian 11 and LDAP is not working with the error:

" Error: Your app key has changed! Could not decrypt LDAP password using your current app key, so LDAP authentication has been disabled. Login with a local account, update the LDAP password and re-enable it in Admin > Settings."

I tried to go in and remove the checkbox for "LDAP Enabled" and hit save, but it didn't do anything. It stayed checked. I went ahead and went to command line and ran the command:

php artisan ldap:disable

And that prevented me from getting into any of the pages for Snipe-It. Then, I entered this command and was able to get back into Snipe-IT

php artisan ldap:sync

Now the box isn't checked anymore, so I went ahead and tried to check it and hit "save" at the bottom and it doesn't check the box. I enabled debug mode and then checked the error and it said this:

[2022-02-28 08:04:23] production.ERROR: Command "snipeit:ldap-enable" is not defined.

Did you mean one of these?
    snipeit:backup
    snipeit:checkin-from-all
    snipeit:checkout-to-all
    snipeit:counter-sync
    snipeit:create-admin
    snipeit:demo-settings
    snipeit:expected-checkin
    snipeit:expiring-alerts
    snipeit:fix-assets-and-logs
    snipeit:import
    snipeit:import-locations
    snipeit:inventory-alerts
    snipeit:ldap-disable
    snipeit:ldap-sync
    snipeit:ldap-sync-ng
    snipeit:legacy-recrypt
    snipeit:merge-users
    snipeit:move-uploads
    snipeit:pave
    snipeit:purge
    snipeit:purge-logins
    snipeit:regenerate-fieldnames
    snipeit:regenerate-tags
    snipeit:restore
    snipeit:restore-users
    snipeit:rotate-key
    snipeit:sync-asset-locations
    snipeit:travisci-install
    snipeit:unescape
    snipeit:upcoming-audits
    snipeit:user-inventory in /var/www/html/snipeit/vendor/symfony/console/Application.php:676
Stack trace:
#0 /var/www/html/snipeit/vendor/symfony/console/Application.php(237): Symfony\Component\Console\Application->find()
#1 /var/www/html/snipeit/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun()
#2 /var/www/html/snipeit/vendor/laravel/framework/src/Illuminate/Console/Application.php(93): Symfony\Component\Console\Application->run()
#3 /var/www/html/snipeit/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(131): Illuminate\Console\Application->run()
#4 /var/www/html/snipeit/artisan(35): Illuminate\Foundation\Console\Kernel->handle()
#5 {main}  

ERROR[2022-02-28 08:04:23] production.ERROR: Symfony\Component\Console\Exception\CommandNotFoundException...

Reproduction steps

Read above

Expected behavior

To be able to enable/disable LDAP

Screenshots

No response

Snipe-IT Version

v5.3.10 - build 6684

Operating System

Debian 11

Web Server

Apache2

PHP Version

7.4

Operating System

No response

Browser

No response

Version

No response

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

No response

Additional context

No response

yosiasz commented 2 years ago

You need to recreate you app key

Christopheric1 commented 2 years ago

I have done this and the same issue is happening

yosiasz commented 2 years ago

might it still be cached with the older key. maybe try to clear cache and retry?

Christopheric1 commented 2 years ago

I just tried to run the commands

php artisan config:clear
php artisan config:cache

and it made no difference

dfitelw commented 2 years ago

Have you logged in via a local SnipeIT account (as in not LDAP integrated) and updated your LDAP bind password?

Christopheric1 commented 2 years ago

I just verified and did it again, so yes. I still can't check the box for LDAP Enabled

uberbrady commented 2 years ago

The LDAP password is encrypted with your APP_KEY - either carry that from the old server to the new, or re-input the LDAP password.

If it’s not that, then it must be that your IP address has changed, and your LDAP server won’t allow the new IP

dfitelw commented 2 years ago

Are there any usable errors in the Snipe log under storage?

Christopheric1 commented 2 years ago

The LDAP password is encrypted with your APP_KEY - either carry that from the old server to the new, or re-input the LDAP password.

If it’s not that, then it must be that your IP address has changed, and your LDAP server won’t allow the new IP

I can't recover it from the old server, and I have tried reinputting the LDAP password and hitting save.

The IP Address is the exact same and LDAP doesn't care as long as you have a pw.

Christopheric1 commented 2 years ago

Are there any usable errors in the Snipe log under storage?

What would be a good way to check the log. It is huge and I don't have time to look through it. What could I specify?

uberbrady commented 2 years ago

take a look at the end.

Christopheric1 commented 2 years ago

take a look at the end.

I have looked and there is nothing of value to do with LDAP

snipe commented 2 years ago

It is huge and I don't have time to look through it.

If you don't have the time to look through it, why would we make the time to help you? That's a helluva statement, dude.

Tail the logs and trigger the error while tailing. If you don't know how to do that, maybe you can find the time to google it. tail -f storage/logs/laravel.log.

Christopheric1 commented 2 years ago

@snipe As the owner, I would hope you know that not everyone knows every command out there. I love your product, but what's with the hostility?

snipe commented 2 years ago

@Christopheric1 I'm not being hostile here. You're telling us you don't have time to look at your logs. Without log info, we cannot help you. Find the time. We're making time for you. Make the time so we can help.

dfitelw commented 2 years ago

I would start with causing the error at least twice and then tail the last 50 lines or so off for review. Note that your above error in your original post shows that snipeit:ldap-enable doesn't seem to exist, and the available commands imply LDAP can only be enabled via the GUI in Snipe not via CLI, but don't quote me.

Are you the same guy discussing this in Discord as well as here?

snipe commented 2 years ago

We're pretty busy on our end here too. We want you to succeed, but we cannot do it without you investing a little time into helping us to help you.

Christopheric1 commented 2 years ago

@snipe All I asked for was a way to look at the end of the code. Next time, I will be more specific so that I don't get people on my back. Yes, we can all Google things, but I am reaching out to the experts. I APPRECIATE any time that anyone can give me here, truly. I am dead in the water and will be willing to do anything you guys ask, I just might need a little coaching. I mean absolutely no disrespect.

snipe commented 2 years ago

I gave you the answer in my reply: tail -f storage/logs/laravel.log. Do that and trigger the error again, and you'll see what's currently breaking based on what the new log stack trace is. We can't point you to code if we don't know what the stack trace says, and the stack trace is in the logs, per our docs.

Christopheric1 commented 2 years ago

I would start with causing the error at least twice and then tail the last 50 lines or so off for review. Note that your above error in your original post shows that snipeit:ldap-enable doesn't seem to exist, and the available commands imply LDAP can only be enabled via the GUI in Snipe not via CLI, but don't quote me.

Are you the same guy discussing this in Discord as well as here?

I am not the guy in Discord. I don't actually have it installed on this computer. I will see if I can run that command and then try to replicate the issue again.

snipe commented 2 years ago

I would recommend cmd+k in your terminal window to clear the past onscreen history and then just copying+pasting here whatever the new error is that pops up when you trigger the error. That will remove any extra noise. It's not required, but will make it easier to see what's changed.

Christopheric1 commented 2 years ago

I did the tail command and I also cleared my screen and then ran the check box and save, and nothing comes up in my terminal window.

dfitelw commented 2 years ago

Have you looked in the apache logs? There's also the "other site" logs which can happen if something weird is going on with the request being handled by Apache.

Christopheric1 commented 2 years ago

Have you looked in the apache logs? There's also the "other site" logs which can happen if something weird is going on with the request being handled by Apache.

Where are these logs located so that I can look through them?

dfitelw commented 2 years ago

I'm on Debian 11 with a relatively default setup for Apache2. image

snipe commented 2 years ago

(If you thought the laravel.log file was big, hold onto your butt.)

Also the PHP error log may be useful here. You can find that location by running php --info | grep error_log

snipe commented 2 years ago

When you ran the tail, you did include the -f flag, right? Otherwise it will show you a static snapshot of the last lines of that file, versus showing you new things as they come in.

Christopheric1 commented 2 years ago

When you ran the tail, you did include the -f flag, right? Otherwise it will show you a static snapshot of the last lines of that file, versus showing you new things as they come in.

I did use the -f and saw the blinking cursor waiting for new info

Christopheric1 commented 2 years ago

I'm on Debian 11 with a relatively default setup for Apache2. image

Thanks for this. I am also on Debian 11. Error.log only shows an error of my cert for SSL, but that is working fine. The other_vhosts_access.log doesn't show anything and the access.log didn't have anything either.

Christopheric1 commented 2 years ago

Here is what I get from that:

root@snipe-it1:/var/www/html/snipeit# php --info | grep error_log
error_log => no value => no value
opcache.error_log => no value => no value
dfitelw commented 2 years ago

I don't recall if you already said this: did you look in the apache log specific to your site? This can live in multiple places including the above /var/log location. I move mine to be close to my site(s) in /var/www/logs personally but that's just me. You may track down a site specific error there.

Christopheric1 commented 2 years ago

I don't recall if you already said this: did you look in the apache log specific to your site? This can live in multiple places including the above /var/log location. I move mine to be close to my site(s) in /var/www/logs personally but that's just me. You may track down a site specific error there.

Here is what I have:

root@snipe-it1:/var/log/apache2# ls
access.log       access.log.6.gz  error.log.11.gz  error.log.7.gz                other_vhosts_access.log.3.gz
access.log.1     access.log.7.gz  error.log.2.gz   error.log.8.gz                other_vhosts_access.log.4.gz
access.log.2.gz  access.log.8.gz  error.log.3.gz   error.log.9.gz                other_vhosts_access.log.5.gz
access.log.3.gz  error.log        error.log.4.gz   other_vhosts_access.log
access.log.4.gz  error.log.1      error.log.5.gz   other_vhosts_access.log.1
access.log.5.gz  error.log.10.gz  error.log.6.gz   other_vhosts_access.log.2.gz
root@snipe-it1:/var/log/apache2#
snipe commented 2 years ago

Okay, try which php (which should tell you which version of PHP you're using, which is hopefully but not always the same as the one Apache is using) and then look in that directory for a php.ini file. Within that file, look for where logs might be.

I feel like we're on the wrong track here though.

Now the box isn't checked anymore, so I went ahead and tried to check it and hit "save" at the bottom and it doesn't check the box.

The code here is pretty straightforward.

https://github.com/snipe/snipe-it/blob/336d8e657442de4d1a5819d2962c587a214b9a8c/resources/views/settings/ldap.blade.php#L61-L73

Unless you have the app in demo mode (which no normal person would ever do), that box should be check-able. Are you saying it's disabled (as in you cannot check it at all) after you've clicked save and revisit the settings page?

Christopheric1 commented 2 years ago

Okay, try which php (which should tell you which version of PHP you're using, which is hopefully but not always the same as the one Apache is using) and then look in that directory for a php.ini file. Within that file, look for where logs might be.

I feel like we're on the wrong track here though.

Now the box isn't checked anymore, so I went ahead and tried to check it and hit "save" at the bottom and it doesn't check the box.

The code here is pretty straightforward.

https://github.com/snipe/snipe-it/blob/336d8e657442de4d1a5819d2962c587a214b9a8c/resources/views/settings/ldap.blade.php#L61-L73

Unless you have the app in demo mode (which no normal person would ever do), that box should be check-able. Are you saying it's disabled (as in you cannot check it at all) after you've clicked save and revisit the settings page?

Here is what I get from which php:

root@snipe-it1:/var/log/apache2# which php
/usr/bin/php

I know I am using php 7.4 due to going through /etc/php/7.4/apache2

This is all I see in php.ini in that particular location:

; Besides displaying errors, PHP can also log errors to locations such as a
; server-specific log, STDERR, or a location specified by the error_log
; directive found below. While errors should not be displayed on productions
; servers they should still be monitored and logging is a great way to do that.
; Default Value: Off
; Development Value: On
; Production Value: On
; http://php.net/log-errors 
log_errors = On
dfitelw commented 2 years ago

My personal site logs are located in /var/www/logs/.log. They're set in apache site files probably easy to spot like this: `grep Log /etc/apache2/sites-enabled/snipe*.conf`

Note this does assume your site config for Apache contains "snipe" in the name somewhere. If not you can try *.conf but that might get harder to read.

snipe commented 2 years ago

Hangon - before we go down this rabbit hole, can I see your .env file, with server names, APP_KEY, and passwords redacted?

Also, do you you know how to connect to your database directly? Either via phpMyAdmin or command line?

Christopheric1 commented 2 years ago

Hangon - before we go down this rabbit hole, can I see your .env file, with server names, APP_KEY, and passwords redacted?

Also, do you you know how to connect to your database directly? Either via phpMyAdmin or command line?


#Created By Snipe-it Installer
# --------------------------------------------
# REQUIRED: BASIC APP SETTINGS
# --------------------------------------------
APP_ENV=production
APP_DEBUG=true
APP_KEY=base64:password
APP_URL=https://snipe-it1.domain
APP_TIMEZONE=US/Pacific
APP_LOCALE=en
MAX_RESULTS=500

--------------------------------------------

REQUIRED: UPLOADED FILE STORAGE SETTINGS

--------------------------------------------

PRIVATE_FILESYSTEM_DISK=local PUBLIC_FILESYSTEM_DISK=local_public

--------------------------------------------

REQUIRED: DATABASE SETTINGS

--------------------------------------------

DB_CONNECTION=mysql DB_HOST=localhost DB_DATABASE=snipeit DB_USERNAME=snipeit DB_PASSWORD='password' DB_PREFIX=null DB_DUMP_PATH='/usr/bin' DB_CHARSET=utf8mb4 DB_COLLATION=utf8mb4_unicode_ci

--------------------------------------------

OPTIONAL: SSL DATABASE SETTINGS

--------------------------------------------

DB_SSL=false DB_SSL_IS_PAAS=false DB_SSL_KEY_PATH=null DB_SSL_CERT_PATH=null DB_SSL_CA_PATH=null DB_SSL_CIPHER=null

--------------------------------------------

REQUIRED: OUTGOING MAIL SERVER SETTINGS

--------------------------------------------

MAIL_DRIVER=smtp MAIL_HOST=smtp.office365.com MAIL_PORT=587 MAIL_USERNAME=xxx MAIL_PASSWORD=xxxx MAIL_ENCRYPTION=STARTTLS MAIL_FROM_ADDR=xxx MAIL_FROM_NAME='Snipe-IT' MAIL_REPLYTO_ADDR=xxx MAIL_REPLYTO_NAME='Snipe-IT' MAIL_AUTO_EMBED_METHOD='attachment'

--------------------------------------------

REQUIRED: IMAGE LIBRARY

This should be gd or imagick

--------------------------------------------

IMAGE_LIB=gd

--------------------------------------------

OPTIONAL: BACKUP SETTINGS

--------------------------------------------

MAIL_BACKUP_NOTIFICATION_DRIVER=null MAIL_BACKUP_NOTIFICATION_ADDRESS=null BACKUP_ENV=true

--------------------------------------------

OPTIONAL: SESSION SETTINGS

--------------------------------------------

SESSION_LIFETIME=12000 EXPIRE_ON_CLOSE=false ENCRYPT=false COOKIE_NAME=snipeit_session COOKIE_DOMAIN=null SECURE_COOKIES=false API_TOKEN_EXPIRATION_YEARS=15

--------------------------------------------

OPTIONAL: SECURITY HEADER SETTINGS

--------------------------------------------

APP_TRUSTED_PROXIES=192.168.1.1,10.0.0.1 ALLOW_IFRAMING=false REFERRER_POLICY=same-origin ENABLE_CSP=false CORS_ALLOWED_ORIGINS=null ENABLE_HSTS=false

--------------------------------------------

OPTIONAL: CACHE SETTINGS

--------------------------------------------

CACHE_DRIVER=file SESSION_DRIVER=file QUEUE_DRIVER=sync CACHE_PREFIX=snipeit

--------------------------------------------

OPTIONAL: REDIS SETTINGS

--------------------------------------------

REDIS_HOST=null REDIS_PASSWORD=null REDIS_PORT=null

--------------------------------------------

OPTIONAL: MEMCACHED SETTINGS

--------------------------------------------

MEMCACHED_HOST=null MEMCACHED_PORT=null

--------------------------------------------

OPTIONAL: PUBLIC S3 Settings

--------------------------------------------

PUBLIC_AWS_SECRET_ACCESS_KEY=null PUBLIC_AWS_ACCESS_KEY_ID=null PUBLIC_AWS_DEFAULT_REGION=null PUBLIC_AWS_BUCKET=null PUBLIC_AWS_URL=null PUBLIC_AWS_BUCKET_ROOT=null

--------------------------------------------

OPTIONAL: PRIVATE S3 Settings

--------------------------------------------

PRIVATE_AWS_ACCESS_KEY_ID=null PRIVATE_AWS_SECRET_ACCESS_KEY=null PRIVATE_AWS_DEFAULT_REGION=null PRIVATE_AWS_BUCKET=null PRIVATE_AWS_URL=null PRIVATE_AWS_BUCKET_ROOT=null

--------------------------------------------

OPTIONAL: LOGIN THROTTLING

--------------------------------------------

LOGIN_MAX_ATTEMPTS=5 LOGIN_LOCKOUT_DURATION=60 RESET_PASSWORD_LINK_EXPIRES=900

--------------------------------------------

OPTIONAL: MISC

--------------------------------------------

APP_LOG=single APP_LOG_MAX_FILES=10 APP_LOCKED=false APP_CIPHER=AES-256-CBC APP_FORCE_TLS=false APP_ALLOW_INSECURE_HOSTS=false GOOGLE_MAPS_API= LDAP_MEM_LIM=500M LDAP_TIME_LIM=600 IMPORT_TIME_LIMIT=600 IMPORT_MEMORY_LIMIT=500M REPORT_TIME_LIMIT=12000



I can connect to it via mysql -u root -p.
snipe commented 2 years ago

APP_KEY=base64:password

This is the redacted version, right? You don't have to tell me what it actually says, I just want to confirm it doesn't literally say "APP_KEY=base64:password"

Christopheric1 commented 2 years ago

APP_KEY=base64:password

This is the redacted version, right? You don't have to tell me what it actually says, I just want to confirm it doesn't literally say "APP_KEY=base64:password"

No, I redacted it

yosiasz commented 2 years ago

My biggest question is on "where I changed servers from CentOS 7 to Debian 11" How did you do that, what methodology did you use? Is the Debian server on same version of snipeit as the CentOS 7 one?

Did you use this method? https://snipe-it.readme.io/docs/moving-snipe-it

Christopheric1 commented 2 years ago

My biggest question is on "where I changed servers from CentOS 7 to Debian 11" How did you do that, what methodology did you use? Is the Debian server on same version of snipeit as the CentOS 7 one?

Did you use this method? https://snipe-it.readme.io/docs/moving-snipe-it

I backed up my old settings based on that method you listed, reinstalled on Debian 11 using these instructions: https://github.com/martinboller/snipeIT-Install Then I moved the info back the best I could minus the .env app_key, so I was going to generate a new one by running the 

php artisan key:generate

and then I cleared the cache and it made no difference

Snipe-IT Documentation
Moving Snipe-IT
Moving/migrating Snipe-IT to a new server should be a pretty painless process. You really only have a few things to worry about: Your .envYour databaseYour uploaded filesYour OAuth keys The easiest way to handle this is to simply run a backup through your Snipe-IT admin panel at Admin > Backups, ...
GitHub
GitHub - martinboller/snipeIT-Install: Installs the Snipe-IT Open Source Asset Management Application on Debian 10/11
Installs the Snipe-IT Open Source Asset Management Application on Debian 10/11 - GitHub - martinboller/snipeIT-Install: Installs the Snipe-IT Open Source Asset Management Application on Debian 10/11
yosiasz commented 2 years ago

How about versions of snipeit ? What you listed there is not really official snipeit install btw

Christopheric1 commented 2 years ago

How about versions of snipeit ? What you listed there is not really official snipeit install btw

I am not sure what the build was before I moved. I know it is not official, but it has worked other than this issue. I even got SSL to work with it. My current build though is v5.3.10 - build 6684

yosiasz commented 2 years ago

Does the other method you used do

php artisan migrate

Because a new version of snipeit it might have db changes

Christopheric1 commented 2 years ago

Does the other method you used do

php artisan migrate

Because a new version of snipeit it might have db changes

I had looked at other articles and saw that command it doesn't end up doing anything. Just says "completed"

yosiasz commented 2 years ago

Hard to commemt on something someone else has cooked up.

If I were you I would use this official approach

https://snipe-it.readme.io/docs/moving-snipe-it

Snipe-IT Documentation
Moving Snipe-IT
Moving/migrating Snipe-IT to a new server should be a pretty painless process. You really only have a few things to worry about: Your .envYour databaseYour uploaded filesYour OAuth keys The easiest way to handle this is to simply run a backup through your Snipe-IT admin panel at Admin > Backups, ...
Christopheric1 commented 2 years ago

Regardless of the how or why, I should still be able to use this instance since everything else imported just fine. I am willing to try whatever, but now I have a bunch of extra data that has been changed since the migration I did a couple of weeks ago.

dfitelw commented 2 years ago

Just a thought: what if you renamed your existing Snipe folder(s), unpacked again and ran the compatibility checker? Have you done that already and did it pass?

yosiasz commented 2 years ago

Regardless of the how or why, I should still be able to use this instance since everything else imported just fine. I am willing to try whatever, but now I have a bunch of extra data that has been changed since the migration I did a couple of weeks ago.

I understand but how and why are in fact 100% relevant.

Try the official move approach. Anything else is just a rabbit hole

Christopheric1 commented 2 years ago

so you are saying rename the root folder at /var/www/html/snipeit to something else and then where would I got to unpack the info as I did that autoinstaller (very nice and easy).