Installing Snipe-IT on CentOS 7 and MariaDB

JaredBusch

@johnhooks said:

@travisdh1 said:
@JaredBusch said:
@travisdh1 said:
@subi15wrx said:

@scottalanmiller Thanks Scott got everything up and running, except I get a nasty red bar across the top of my screen "WARNING: This application is running in production mode with debugging enabled. This can expose sensitive data if your application is accessible to the outside world. Disable debug mode by setting the debug value app/config/production/app.php to false."

Could you point me in the right direct.
 nano /var/www/html/app/config/production/app.php
Change the Disable debug mode line to end with false instead of true.
Save and close. Restart the webserver
systemctl restart httpd
Shouldn't be all that difficult, the error message spells it out quite clearly.
nano is not installed in a minimal setup by default. he will have to either use vi or install nano first yum -y install nano
I'm forever forgetting about that, it's installed in the base image I use. I also have an unnatural loathing of vi and vim. Neither has really made me happy to be using it. If you ask me, keep your sanity, use nano
Ha I've forced myself to use Vi and Vim and now I find myself typing :wq when I want to exit things like gedit and Atom.

I can use vi, I prefer not to. I always install nano along with wget and epel-release

travisdh1

@johnhooks said:

@travisdh1 said:
@JaredBusch said:
@travisdh1 said:
@subi15wrx said:

@scottalanmiller Thanks Scott got everything up and running, except I get a nasty red bar across the top of my screen "WARNING: This application is running in production mode with debugging enabled. This can expose sensitive data if your application is accessible to the outside world. Disable debug mode by setting the debug value app/config/production/app.php to false."

Could you point me in the right direct.
 nano /var/www/html/app/config/production/app.php
Change the Disable debug mode line to end with false instead of true.
Save and close. Restart the webserver
systemctl restart httpd
Shouldn't be all that difficult, the error message spells it out quite clearly.
nano is not installed in a minimal setup by default. he will have to either use vi or install nano first yum -y install nano
I'm forever forgetting about that, it's installed in the base image I use. I also have an unnatural loathing of vi and vim. Neither has really made me happy to be using it. If you ask me, keep your sanity, use nano
Ha I've forced myself to use Vi and Vim and now I find myself typing :wq when I want to exit things like gedit and Atom.

Yanking and pasting are awesome features for Vim though. Being able to type ya( to copy everything between parenthesis is really nice.

Yep, nothing wrong with them, and very powerful tools for working with text. Command structure just never really clicked in my brain tho, whereas nano just meshed so much easier for me.

stacksofplates

@travisdh1 said:

@johnhooks said:
@travisdh1 said:
@JaredBusch said:
@travisdh1 said:
@subi15wrx said:

@scottalanmiller Thanks Scott got everything up and running, except I get a nasty red bar across the top of my screen "WARNING: This application is running in production mode with debugging enabled. This can expose sensitive data if your application is accessible to the outside world. Disable debug mode by setting the debug value app/config/production/app.php to false."

Could you point me in the right direct.
 nano /var/www/html/app/config/production/app.php
Change the Disable debug mode line to end with false instead of true.
Save and close. Restart the webserver
systemctl restart httpd
Shouldn't be all that difficult, the error message spells it out quite clearly.
nano is not installed in a minimal setup by default. he will have to either use vi or install nano first yum -y install nano
I'm forever forgetting about that, it's installed in the base image I use. I also have an unnatural loathing of vi and vim. Neither has really made me happy to be using it. If you ask me, keep your sanity, use nano
Ha I've forced myself to use Vi and Vim and now I find myself typing :wq when I want to exit things like gedit and Atom.

Yanking and pasting are awesome features for Vim though. Being able to type ya( to copy everything between parenthesis is really nice.
Yep, nothing wrong with them, and very powerful tools for working with text. Command structure just never really clicked in my brain tho, whereas nano just meshed so much easier for me.

I definitely don't use hardly 1% of the things it can do. I just found things like typing / to search easier than ctrl+w(or whatever it is in nano)

stacksofplates

I've definitely had times where I got stuck in some weird mode though and had no idea how to exit other than doing :q! and losing my work.

coliver

@johnhooks said:

I've definitely had times where I got stuck in some weird mode though and had no idea how to exit other than doing :q! and losing my work.

Yep... this happens with me on Debian based systems often. On CentOS I can fly through vi but on Debian systems some of the default options change and that makes working in it so much more difficult.

scottalanmiller

I haven't used emacs since around 1990 and have never seen joe or nano. I know that people like that. I had it drilled into me in 1994 to never use anything but vi and I never have since.

stacksofplates

@coliver said:

@johnhooks said:

I've definitely had times where I got stuck in some weird mode though and had no idea how to exit other than doing :q! and losing my work.

Yep... this happens with me on Debian based systems often. On CentOS I can fly through vi but on Debian systems some of the default options change and that makes working in it so much more difficult.

That's where I get it too. I still haven't figured out what they changed. Glad to see it's not just me haha.

scottalanmiller

@johnhooks said:

@coliver said:

@johnhooks said:

I've definitely had times where I got stuck in some weird mode though and had no idea how to exit other than doing :q! and losing my work.

Yep... this happens with me on Debian based systems often. On CentOS I can fly through vi but on Debian systems some of the default options change and that makes working in it so much more difficult.

That's where I get it too. I still haven't figured out what they changed. Glad to see it's not just me haha.

I find that avoiding Debian fixes that

travisdh1

@scottalanmiller said:

@johnhooks said:

@coliver said:

@johnhooks said:

I've definitely had times where I got stuck in some weird mode though and had no idea how to exit other than doing :q! and losing my work.

Yep... this happens with me on Debian based systems often. On CentOS I can fly through vi but on Debian systems some of the default options change and that makes working in it so much more difficult.

That's where I get it too. I still haven't figured out what they changed. Glad to see it's not just me haha.

I find that avoiding Debian fixes that

Just for the record, IRIX's vi was just as bad. Wonder if it came from the same source. Tho IRIX was an abandoned OS ~14 years ago now.

scottalanmiller

I've used a lot of different vi variants over the years. CentOS is actually using vim with lots of enhancements. I use very few of them, though.

subi15wrx

@travisdh1 Thanks Travis, please forgive me, my issue was I was having a hard time finding the exact path of /var/www/html/snipeit/app/config/production/app.php I am still quite a bit of a noob.

scottalanmiller

@subi15wrx said:

@travisdh1 Thanks Travis, please forgive me, my issue was I was having a hard time finding the exact path of /var/www/html/snipeit/app/config/production/app.php I am still quite a bit of a noob.

Did you get it all working now without the error message?

subi15wrx

@scottalanmiller All good Scott, thanks again to everyone for you help and patients

travisdh1

@subi15wrx said:

@travisdh1 Thanks Travis, please forgive me, my issue was I was having a hard time finding the exact path of /var/www/html/snipeit/app/config/production/app.php I am still quite a bit of a noob.

Yep, that'll do it all right. That path is one of the many things a lot of Linux Admins would take for granted.

scottalanmiller

@travisdh1 said:

@subi15wrx said:

@travisdh1 Thanks Travis, please forgive me, my issue was I was having a hard time finding the exact path of /var/www/html/snipeit/app/config/production/app.php I am still quite a bit of a noob.

Yep, that'll do it all right. That path is one of the many things a lot of Linux Admins would take for granted.

One of the many "things that people might assume" items I am attempting to address in that Linux Admin series.

scottalanmiller

I'd have another article out already if I wasn't documenting an OpenFire installation for people today.

JaredBusch

@scottalanmiller said:

I'd have another article out already if I wasn't documenting an OpenFire installation for people today.

Still waiting on your ELK article

scottalanmiller

I feel like suddenly there are a lot of installation articles needed

travisdh1

@scottalanmiller said:

I feel like suddenly there are a lot of installation articles needed

Always were, probably more than a single person could ever cover.

subi15wrx

@scottalanmiller said:

@subi15wrx said:

@travisdh1 Thanks Travis, please forgive me, my issue was I was having a hard time finding the exact path of /var/www/html/snipeit/app/config/production/app.php I am still quite a bit of a noob.

Did you get it all working now without the error message?

Hey Scott,

I just noticed today after I restarted the system I am now getting error "Error in exception handler: The stream or file "/var/www/html/snipeit/app/storage/logs/log-apache2handler-2016-02-11.txt" could not be opened: failed to open stream: Permission denied in /var/www/html/snipeit/vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php:87" when navigating to the home page.

shot in the dark might be permissions related?