Got a chuckle out of this email this morning from Lenovo.

Subject: Is your company's data secure?

Answer: Yes, because we don't use Lenovo

Lol I'm always baffled at how seemingly straightforward threads can get you down a rabbit hole 66 posts later. Everything from "stop letting them have the internets" to get a new internet line for voice.

Is this not a simple solution of implementing QoS for VoIP at the firewall/router and moving on? That's every solution I've ever heard preached by @scottalanmiller and @JaredBusch in regards to this issue. Then it doesn't matter if you have a 10Mbps connection or 1Gbps, it will never allow bandwidth usage to exceed what VoIP needs to ensure you always have a solid VoIP service. If it's not that simple, someone please straighten me out. I don't see why an extra internet line or VLANS are necessary.

We have similar options where I work. My understanding is that the "shared fiber" is basically similar to home internet access. When your neighbors are noisy or consuming high traffic, in can in turn affect the speed and quality of internet that you receive.

A dedicated circuit on the other hand brings their router to your building and guarantees you the speed you pay for regardless of what your neighbors are doing next door.

With my ISP, they also state that in the case of an outage, dedicated circuit customers get serviced first. With that said, I think the ISP was down for a total of 4 minutes last year.

When we first got our service at my office, they didn't offer anything but dedicated. Now they offer shared, and we're considering going to it but I'm trying to find customers who have used the shared product to see how well it works in comparison.

Dedicated is 2 to 3 times greater cost than shared service

@coliver said in Miscellaneous Tech News:

@zachary715 said in Miscellaneous Tech News:

@scottalanmiller said in Miscellaneous Tech News:

@coliver said in Miscellaneous Tech News:

Unless Dell is trying to cash out? I'm not sure how that would work for him actually.

Very possible, but that was SO much work to get private, too much for a quick cash out I think.

There's a firm that helped Michael Dell take the company private. Very possible they're wanting to cash out and going public is the way to do it. Who knows.

From what I've read it was a firm he founded and held majority share of. He was the sole person to bring Dell private. Either he's trying for a quick cash out, which wouldn't make much sense since Dell just took over EMC and VMWare, or he's going to get out of the game and the company can't afford to buy him out. Either way seems very unlikely.

Silver Lake was the name of the firm. Looks like they helped Dell take the company private and currently own about 18%. This is just one reason people are speculating they are considering this move

https://www.cnbc.com/2018/01/26/dell-is-considering-acquisitions-or-a-possible-ipo-sources.html

From the article...

Another consideration for Dell in its deliberations is offering a path to private equity firm Silver Lake 
to cash out on its investment in the company. Silver Lake helped bankroll Michael Dell's $24.9 billion 
deal in 2013 to take the company private and owns about 18 percent of the company.

@scottalanmiller said in Miscellaneous Tech News:

@coliver said in Miscellaneous Tech News:

Unless Dell is trying to cash out? I'm not sure how that would work for him actually.

Very possible, but that was SO much work to get private, too much for a quick cash out I think.

There's a firm that helped Michael Dell take the company private. Very possible they're wanting to cash out and going public is the way to do it. Who knows.

@black3dynamite said in Snipe-IT PHP 5.6 upgrade to 7.1:

@zachary715 said in Snipe-IT PHP 5.6 upgrade to 7.1:

So just spun up a new Fedora VM and installed Snipe-IT via script.

If I click the link about testing the .env file, it goes to the 404 page as expected. If I click next...

Temporary disable SELinux and try again.
setenforce 0

So that makes the .env file section of the pre-flight page go green, but next page still shows the "Whoops" page. Should I try to reinstall but precede the installation with setenforce 0?

@dustinb3403 said in Snipe-IT PHP 5.6 upgrade to 7.1:

the 404 page, IIRC means its working as intended

and that this test, actually is a false alarm.

Correct. Looking for logs now to post and see if someone can help spot the issue. Can't remember where I found them before.

So just spun up a new Fedora VM and installed Snipe-IT via script.

If I click the link about testing the .env file, it goes to the 404 page as expected. If I click next...

@dustinb3403 said in Snipe-IT PHP 5.6 upgrade to 7.1:

I guess the core question I have that is irritating me is why can't I just point snipe-it to the updated version of php?

Did you attempt @black3dynamite's method above?

@jaredbusch said in Snipe-IT PHP 5.6 upgrade to 7.1:

@dustinb3403 said in Snipe-IT PHP 5.6 upgrade to 7.1:

None of this relates to my issue of "how the H do I upgrade php without borking the whole damn thing..." lol

It does, because our answer is to install clean and migrate the DB.

And you will get an updated version of PHP as you wish

@black3dynamite said in Snipe-IT PHP 5.6 upgrade to 7.1:

@zachary715 said in Snipe-IT PHP 5.6 upgrade to 7.1:

@jaredbusch said in Snipe-IT PHP 5.6 upgrade to 7.1:

@scottalanmiller said in Snipe-IT PHP 5.6 upgrade to 7.1:

@dustinb3403 said in Snipe-IT PHP 5.6 upgrade to 7.1:

@scottalanmiller said in Snipe-IT PHP 5.6 upgrade to 7.1:

Instead of upgrading, why not move to a fresh box with working PHP 7.1? Keep the two separate, just copy over the database.

Because I'd have to reinstall everything. . .

Um... reinstall what? It only takes a minute. And if you scripted, or followed a script, or used Ansible, Salt, etc. it's just a push of a button away.

The scripted install uses PHP 5.6 on CentOS 7.

He would need to move to Fedora to get around that.

I just installed Snipe-IT on CentOS 7 the other day via the install.sh script and it's running PHP 7.1.13. The script kept failing on Fedora 27.

What happens when using the script on Fedora?

I would get to the pre-flight page and everything would look good. I would have a red X next to the part about the .env file but all the settings inside it looked correct. If I clicked next, I would get a page saying that "Whoops, something went wrong". Tried to install it 4 different times with same result.

@jaredbusch said in Snipe-IT PHP 5.6 upgrade to 7.1:

@zachary715 said in Snipe-IT PHP 5.6 upgrade to 7.1:

@jaredbusch said in Snipe-IT PHP 5.6 upgrade to 7.1:

@scottalanmiller said in Snipe-IT PHP 5.6 upgrade to 7.1:

@dustinb3403 said in Snipe-IT PHP 5.6 upgrade to 7.1:

@scottalanmiller said in Snipe-IT PHP 5.6 upgrade to 7.1:

Instead of upgrading, why not move to a fresh box with working PHP 7.1? Keep the two separate, just copy over the database.

Because I'd have to reinstall everything. . .

Um... reinstall what? It only takes a minute. And if you scripted, or followed a script, or used Ansible, Salt, etc. it's just a push of a button away.

The scripted install uses PHP 5.6 on CentOS 7.

He would need to move to Fedora to get around that.

I just installed Snipe-IT on CentOS 7 the other day via the install.sh script and it's running PHP 7.1.13. The script kept failing on Fedora 27.

Damnit, I had it all workign. Did someone update snipe.sh again?

I had previously installed it on Fedora 26 and had no issues. I looked at some logs but honestly couldn't figure it out and didn't have the time to dedicate to troubleshooting. Just tried CentOS 7 to see if I'd get the same message and it worked flawlessly.

@jaredbusch said in Snipe-IT PHP 5.6 upgrade to 7.1:

@scottalanmiller said in Snipe-IT PHP 5.6 upgrade to 7.1:

@dustinb3403 said in Snipe-IT PHP 5.6 upgrade to 7.1:

@scottalanmiller said in Snipe-IT PHP 5.6 upgrade to 7.1:

Instead of upgrading, why not move to a fresh box with working PHP 7.1? Keep the two separate, just copy over the database.

Because I'd have to reinstall everything. . .

Um... reinstall what? It only takes a minute. And if you scripted, or followed a script, or used Ansible, Salt, etc. it's just a push of a button away.

The scripted install uses PHP 5.6 on CentOS 7.

He would need to move to Fedora to get around that.

I just installed Snipe-IT on CentOS 7 the other day via the install.sh script and it's running PHP 7.1.13. The script kept failing on Fedora 27.

I'm trying to format mine similar to our file server structure so that it's easily recognizable by users. This will also hopefully make permission settings easier to apply and keep it from getting crazy.

Generally, I have top-level pages, or departments in my case, as just a reference page with links to the numerous subpages. Then if any subpages need subpages, then same thing.

@nerdydad said in Miscellaneous Tech News:

@zachary715 said in Miscellaneous Tech News:

Dell considering returning public, other options as they look to raise capital... https://www.bloomberg.com/news/articles/2018-01-26/dell-technologies-is-said-to-be-considering-ipo-other-options

One of the things I like about Dell is the fact that they are a private company, therefore don't have the pressures to do things that may not be the best decision for consumers in order to please shareholders. Will be watching this play out and see what changes this might bring.

Just because you are private, doesn't mean you don't have shareholders. Its just that they are not publicly traded on a stock exchange. Pressure of shareholders could still be there. You just wouldn't have the SEC breathing down your neck.

But it does mean your name isn't in the news every quarter when you report earnings and people nit-picking your statements. This is what I'm referring to. As a private company, you can generally make better long-term decisions with less scrutiny than you could as a public company.

Dell considering returning public, other options as they look to raise capital... https://www.bloomberg.com/news/articles/2018-01-26/dell-technologies-is-said-to-be-considering-ipo-other-options

One of the things I like about Dell is the fact that they are a private company, therefore don't have the pressures to do things that may not be the best decision for consumers in order to please shareholders. Will be watching this play out and see what changes this might bring.

@stacksofplates said in Intranet suggestions....:

@nashbrydges said in Intranet suggestions....:

Any of these options recommended for a multi-client scenario? Would need authentication so each client only accesses their own documentation.

Yes drupal can do that. Wiki.js can have roles and users that have access to specific areas but I've noticed if you search for something, the search show up in the bar from areas they don't have access to. They can't get there, but the titles and such show up.

@black3dynamite said in Intranet suggestions....:

@stacksofplates said in Intranet suggestions....:

@black3dynamite said in Intranet suggestions....:

@stacksofplates said in Intranet suggestions....:

@scottalanmiller said in Intranet suggestions....:

@stacksofplates said in Intranet suggestions....:

@nashbrydges said in Intranet suggestions....:

Any of these options recommended for a multi-client scenario? Would need authentication so each client only accesses their own documentation.

Yes drupal can do that. Wiki.js can have roles and users that have access to specific areas but I've noticed if you search for something, the search show up in the bar from areas they don't have access to. They can't get there, but the titles and such show up.

Search is so often a week point in security, argh. If all you are doing is hiding passwords or details, it often works fine. If you are hiding concepts, it's useless.

Ya I was really disappointed when I saw that. So you need multiple sites for separation, which sucks.

Is it still an issue if Wiki.js is not setup for public access?

Yes because you don't want clients seeing info for other clients. And we were going to use it for a user area and an internal documentation site. But that won't work now.

What about creating rules to allow users to see what you want them to see?

https://docs.requarks.io/wiki/admin-guide/manage-access-rights

I think what @stacksofplates was saying above was that you can use these rules to permit access, but the search still allows you to see some of the content. If you try to select it it won't take you to the page and allow you to see the full content, but the search may give you headlines or even a little data that shouldn't be visible without permissions. This is something that hopefully they will be able to iron out moving forward.

@scottalanmiller said in Installing Wiki.js on CentOS 7:

Wiki.js is a NodeBB based modern wiki that can be installed on nearly any OS. We will run through a simple install on CentOS 7.

I think you meant NodeJS here...

@scottalanmiller said in Installing Wiki.js on CentOS 7:

@zachary715 said in Installing Wiki.js on CentOS 7:

@jaredbusch said in Installing Wiki.js on CentOS 7:

@scottalanmiller said in Installing Wiki.js on CentOS 7:

@jaredbusch said in Installing Wiki.js on CentOS 7:

Why are people using CentOS for This? Nothing on their website says it has to be on this.

Anyone using CentOS other than me? I'm using it because it is our existing standard platform for NodeJS deployments and we aren't moving from it anytime soon. I was asked to document my process, so I did. It should be even simpler to do it on Fedora, that's just not where I'm deploying right now.

Yes, one other in another thread was talking about CentOS for some reason. While someone else said they used Ubuntu I believe.

I used Ubuntu because it's what their documentation recommended.

Sort of, @wirestyle22 and I dug into that and while the docs say that, it's also pretty clear that they just don't update the docs, sadly. And they only document an install of Debian. They are all over the place. They don't exactly recommend old OSes like Ubuntu 16.04 and Windows 2012 R2, but point out that they are "more tested", which should be obvious since they are old. But that's not the same as recommended.

"More tested" doesn't mean "more stable", already broken down old things are often better tested than new, reliable ones. A barely functional 1975 Pinto is "better tested" than a brand new BMW 335i, but the new BMW is probably less likely to leave you stranded.

They word things a bit funny there and between that and not updating well, it can lead you in some weird directions. Not that Ubuntu is bad, but I don't think that they intend to recommend it in any way.

Wiki.js runs on pretty much any platform that supports the requirements below. However, the following environments are recommended and more thoroughly tested:

Ubuntu Server 16.04 LTS
Windows Server 2012 R2

I did not interpret that to mean that the OS itself was more tested, but rather that had tested Wiki.js on these OSes more so than others. They make it clear it can run on any system though. I just chose to go with what they had claimed to have tested for and it's worked out for me thus far.

@jaredbusch said in Installing Wiki.js on CentOS 7:

@scottalanmiller said in Installing Wiki.js on CentOS 7:

@jaredbusch said in Installing Wiki.js on CentOS 7:

Why are people using CentOS for This? Nothing on their website says it has to be on this.

Anyone using CentOS other than me? I'm using it because it is our existing standard platform for NodeJS deployments and we aren't moving from it anytime soon. I was asked to document my process, so I did. It should be even simpler to do it on Fedora, that's just not where I'm deploying right now.

Yes, one other in another thread was talking about CentOS for some reason. While someone else said they used Ubuntu I believe.

I used Ubuntu because it's what their documentation recommended.