So for anyone else who may stumble across this, here is the concise solution that worked for me.
sudo chown -R www-data:www-data ./storage
sudo chmod -R 755 ./storage
This sets the owner and permissions for all the files in the storage folder for Snipe-IT.
Then run sudo -u www-data php upgrade.php
This still spat out a few errors, but they seem to be inconsequential, and everything is updated.
It finished, but with these errors:
Step 4: Cleaning up old cached files:
--------------------------------------------------------
-- No bootstrap/cache/compiled.php, so nothing to delete.
-- Deleting bootstrap/cache/services.php. It it no longer used.
-- Deleting bootstrap/cache/config.php. It it no longer used.
--
In ProviderRepository.php line 208:
Class 'PragmaRX\Google2FALaravel\ServiceProvider' not found
--
In ProviderRepository.php line 208:
Class 'PragmaRX\Google2FALaravel\ServiceProvider' not found
--
In ProviderRepository.php line 208:
Class 'PragmaRX\Google2FALaravel\ServiceProvider' not found
--
In ProviderRepository.php line 208:
Class 'PragmaRX\Google2FALaravel\ServiceProvider' not found
And
--------------------------------------------------------
Step 5: Updating composer dependencies:
(This may take an moment.)
--------------------------------------------------------
-- We couldn't find a local composer.phar - trying globally.
Cannot create cache directory /home/jcoombes/.composer/cache/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/jcoombes/.composer/cache/files/, or directory is not writable. Proceeding without cache
<snip>
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover
In ProviderRepository.php line 208:
Class 'PragmaRX\Google2FALaravel\ServiceProvider' not found
<snip>
Package manifest generated successfully.
But other than that it appears to have worked out just fine.
Are there any security concerns with the .git files now being owned by www-data with 755 permissions?
For some reason the FETCH_HEAD file was owned by root, and several other things in the .git folder, so I changed them all to www-data:www-data.
It is running now, and updating a bunch of things. Hopefully that will do it.
I'll take you word for that. The end result is it is not upgrading anything. I am still on 4.6.7 when it is done.
To be clear, you are saying that this is normal?
--------------------------------------------------------
STEP 3: Pulling latest from Git (master branch):
--------------------------------------------------------
Git is installed.
Already on 'master'
error: cannot open .git/FETCH_HEAD: Permission denied
-- No local changes to save
-- Your branch is up to date with 'origin/master'.
And this:
--------------------------------------------------------
Step 5: Updating composer dependencies:
(This may take an moment.)
--------------------------------------------------------
-- We couldn't find a local composer.phar - trying globally.
Cannot create cache directory /home/jcoombes/.composer/cache/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/jcoombes/.composer/cache/files/, or directory is not writable. Proceeding without cache
Generating optimized autoload files
Cannot create cache directory /home/jcoombes/.composer/cache/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/jcoombes/.composer/cache/files/, or directory is not writable. Proceeding without cache
Loading composer repositories with package information
Installing dependencies from lock file
Nothing to install or update
Generating optimized autoload files
@black3dynamite said in Snipe-IT Upgrade from 4.6.7 to 4.7.5 not working.:
sudo -u www-data php upgrade.php
That makes sense, and seems to have solved the backup issue and some of the permission errors, but now I am getting this:
Welcome to the Snipe-IT upgrader.
Please note that this script will not download the latest Snipe-IT
files for you unless you have git installed.
It simply runs the standard composer and artisan
commands needed to finalize the upgrade after.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! If you have any encrypted custom fields, BE SURE TO run the recrypter if upgrading from v3 to v4.
!! See the Snipe-IT documentation for help:
!! https://snipe-it.readme.io/docs/upgrading-to-v4
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--------------------------------------------------------
STEP 1: Backing up database:
--------------------------------------------------------
-- Starting backup...
Dumping database snipeit_data...
Determining files to backup...
Zipped 79 files...
Copying 2019-07-30-145900.zip (size: 806.26 KB) to disk named local...
Successfully copied .zip file to disk named local.
Backup completed!
--------------------------------------------------------
STEP 2: Putting application into maintenance mode:
--------------------------------------------------------
-- Application is now in maintenance mode.
--------------------------------------------------------
STEP 3: Pulling latest from Git (master branch):
--------------------------------------------------------
Git is installed.
Already on 'master'
error: cannot open .git/FETCH_HEAD: Permission denied
-- No local changes to save
-- Your branch is up to date with 'origin/master'.
-- --------------------------------------------------------
Step 4: Cleaning up old cached files:
--------------------------------------------------------
-- No bootstrap/cache/compiled.php, so nothing to delete.
-- Deleting bootstrap/cache/services.php. It it no longer used.
-- Deleting bootstrap/cache/config.php. It it no longer used.
-- Configuration cache cleared!
-- Cache cleared successfully.
-- Route cache cleared!
-- Compiled views cleared!
--------------------------------------------------------
Step 5: Updating composer dependencies:
(This may take an moment.)
--------------------------------------------------------
-- We couldn't find a local composer.phar - trying globally.
Cannot create cache directory /home/jcoombes/.composer/cache/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/jcoombes/.composer/cache/files/, or directory is not writable. Proceeding without cache
Generating optimized autoload files
Cannot create cache directory /home/jcoombes/.composer/cache/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/jcoombes/.composer/cache/files/, or directory is not writable. Proceeding without cache
Loading composer repositories with package information
Installing dependencies from lock file
Nothing to install or update
Generating optimized autoload files
--------------------------------------------------------
Step 6: Migrating database:
--------------------------------------------------------
-- Nothing to migrate.
--------------------------------------------------------
Step 7: Checking for OAuth keys:
--------------------------------------------------------
- OAuth keys detected. Skipping passport install.
--------------------------------------------------------
Step 8: Caching routes and config:
--------------------------------------------------------
-- Configuration cache cleared!
Configuration cached successfully!
-- Route cache cleared!
Routes cached successfully!
--------------------------------------------------------
Step 9: Taking application out of maintenance mode:
--------------------------------------------------------
-- Application is now live.
--------------------------------------------------------
FINISHED! Clear your browser cookies and re-login to use :
your upgraded Snipe-IT.
--------------------------------------------------------
Ubuntu Server 18.04 LTS with all the latest updates (as of today).
I tried running php upgrade.php and got:
Welcome to the Snipe-IT upgrader.
Please note that this script will not download the latest Snipe-IT
files for you unless you have git installed.
It simply runs the standard composer and artisan
commands needed to finalize the upgrade after.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! If you have any encrypted custom fields, BE SURE TO run the recrypter if upgrading from v3 to v4.
!! See the Snipe-IT documentation for help:
!! https://snipe-it.readme.io/docs/upgrading-to-v4
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--------------------------------------------------------
STEP 1: Backing up database:
--------------------------------------------------------
-- Starting backup...
Dumping database snipeit_data...
Backup failed because The dump process failed with exitcode 2 : Misuse of shell builtins : sh: 1: cannot create /var/www/snipe-it/storage/laravel-backups/temp//snipeit_data.sql: Directory nonexistent
.
Backup failed because: The stream or file "/var/www/snipe-it/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied.
In StreamHandler.php line 107:
The stream or file "/var/www/snipe-it/storage/logs/laravel.log" could not be opened: f
ailed to open stream: Permission denied
--------------------------------------------------------
STEP 2: Putting application into maintenance mode:
--------------------------------------------------------
--
In StreamHandler.php line 107:
The stream or file "/var/www/snipe-it/storage/logs/laravel.log" could not be opened: f
ailed to open stream: Permission denied
--------------------------------------------------------
STEP 3: Pulling latest from Git (master branch):
--------------------------------------------------------
Git is installed.
fatal: Unable to create '/var/www/snipe-it/.git/index.lock': Permission denied
fatal: Unable to create '/var/www/snipe-it/.git/index.lock': Permission denied
Cannot save the current index state
error: cannot open .git/FETCH_HEAD: Permission denied
-- -- -- --------------------------------------------------------
Step 4: Cleaning up old cached files:
--------------------------------------------------------
-- No bootstrap/cache/compiled.php, so nothing to delete.
-- Deleting bootstrap/cache/services.php. It it no longer used.
-- No bootstrap/cache/config.php, so nothing to delete.
-- Configuration cache cleared!
-- Cache cleared successfully.
-- Route cache cleared!
-- Compiled views cleared!
--------------------------------------------------------
Step 5: Updating composer dependencies:
(This may take an moment.)
--------------------------------------------------------
-- We couldn't find a local composer.phar - trying globally.
Cannot create cache directory /home/jcoombes/.composer/cache/repo/https---repo.packagist.org/, or directory is not writable. Proceeding without cache
Cannot create cache directory /home/jcoombes/.composer/cache/files/, or directory is not writable. Proceeding without cache
Generating optimized autoload files
^C
You can see I killed it at the end there. So I moved onto trying to update manually, so I started by running php artisan snipeit:backup and got:
Starting backup...
Dumping database snipeit_data...
Backup failed because The dump process failed with exitcode 2 : Misuse of shell builtins : sh: 1: cannot create /var/www/snipe-it/storage/laravel-backups/temp//snipeit_data.sql: Directory nonexistent
.
Backup failed because: The stream or file "/var/www/snipe-it/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied.
In StreamHandler.php line 107:
The stream or file "/var/www/snipe-it/storage/logs/laravel.log" could not be opened: f
ailed to open stream: Permission denied
So I am reasonably sure that this is a permissions issue, though I cannot for the life of me think how those got screwed up, and I am absolutely not sure what they should be set to.
Can anyone help me with this?
Here is the ls output for the folder:
ls -alh
total 1016K
drwxr-xr-x 16 www-data www-data 4.0K Jan 15 2019 .
drwxr-xr-x 4 root root 4.0K Nov 1 2018 ..
-rw-r--r-- 1 www-data www-data 44K Nov 1 2018 .all-contributorsrc
drwxr-xr-x 17 www-data www-data 4.0K Nov 1 2018 app
-rw-r--r-- 1 www-data www-data 1.7K Nov 1 2018 artisan
drwxr-xr-x 3 www-data www-data 4.0K Nov 1 2018 bootstrap
-rw-r--r-- 1 www-data www-data 875 Nov 1 2018 bower.json
-rw-r--r-- 1 www-data www-data 9.0K Nov 1 2018 c3.php
-rw-r--r-- 1 www-data www-data 373 Nov 1 2018 codeception.yml
-rw-r--r-- 1 www-data www-data 3.2K Nov 1 2018 CODE_OF_CONDUCT.md
-rw-r--r-- 1 www-data www-data 2.3K Nov 1 2018 composer.json
-rw-r--r-- 1 www-data www-data 227K Nov 1 2018 composer.lock
drwxr-xr-x 2 www-data www-data 4.0K Jan 15 2019 config
-rw-r--r-- 1 www-data www-data 317 Nov 1 2018 CONTRIBUTING.md
-rw-r--r-- 1 www-data www-data 90 Nov 1 2018 crowdin.yml
drwxr-xr-x 5 www-data www-data 4.0K Nov 1 2018 database
drwxr-xr-x 2 www-data www-data 4.0K Nov 1 2018 docker
-rw-r--r-- 1 www-data www-data 3.2K Nov 1 2018 Dockerfile
-rw-r--r-- 1 www-data www-data 67 Nov 1 2018 .dockerignore
-rw-r--r-- 1 www-data www-data 2.8K Nov 1 2018 .env
-rw-r--r-- 1 root root 2.9K Jan 15 2019 .env.example
-rw-r--r-- 1 www-data www-data 1.8K Nov 1 2018 .env.testing
-rw-r--r-- 1 www-data www-data 1.8K Nov 1 2018 .env.testing-ci
-rw-r--r-- 1 www-data www-data 536 Nov 1 2018 .env.tests
-rw-r--r-- 1 www-data www-data 491 Nov 1 2018 .env.unit-tests
-rw-r--r-- 1 www-data www-data 1.7K Nov 1 2018 gh-changelog.php
drwxr-xr-x 8 www-data www-data 4.0K Jan 15 2019 .git
-rwxr-xr-x 1 www-data www-data 11 Nov 1 2018 .gitattributes
drwxr-xr-x 3 www-data www-data 4.0K Nov 1 2018 .github
-rwxr-xr-x 1 www-data www-data 1.1K Nov 1 2018 .gitignore
-rw-r--r-- 1 www-data www-data 251 Nov 1 2018 .htaccess
-rw-r--r-- 1 www-data www-data 956 Nov 1 2018 index.html
-rwxr-xr-x 1 www-data www-data 371 Nov 1 2018 install.sh
-rwxr-xr-x 1 www-data www-data 34K Nov 1 2018 LICENSE
-rw-r--r-- 1 www-data www-data 441K Nov 1 2018 npm-shrinkwrap.json
-rw-r--r-- 1 www-data www-data 1.8K Nov 1 2018 package.json
-rw-r--r-- 1 www-data www-data 1.1K Nov 1 2018 phpunit.xml
drwxr-xr-x 8 www-data www-data 4.0K Jan 15 2019 public
-rw-r--r-- 1 www-data www-data 45K Nov 1 2018 README.md
drwxr-xr-x 6 www-data www-data 4.0K Nov 1 2018 resources
drwxr-xr-x 3 www-data www-data 4.0K Nov 1 2018 routes
drwxr-xr-x 2 www-data www-data 4.0K Nov 1 2018 sample_csvs
-rw-r--r-- 1 www-data www-data 567 Nov 1 2018 server.php
-rwxr-xr-x 1 www-data www-data 22K Nov 1 2018 snipeit.sh
drwxrwxr-x 7 www-data www-data 4.0K Nov 1 2018 storage
drwxr-xr-x 10 www-data www-data 4.0K Nov 1 2018 tests
-rw-r--r-- 1 root root 2.8K Jan 15 2019 .travis.yml
-rw-r--r-- 1 www-data www-data 6.1K Nov 1 2018 upgrade.php
-rw-r--r-- 1 www-data www-data 3.4K Nov 1 2018 Vagrantfile
drwxr-xr-x 51 www-data www-data 4.0K Nov 1 2018 vendor
-rw-r--r-- 1 www-data www-data 2.1K Nov 1 2018 webpack.mix.js
EDIT: I just changed the permissions on everything in the /var/www/snipe-it folder to 755, and made sure that everything is owned by www-data and the group is www-data. I am still getting all these permission errors when trying to upgrade.
@scottalanmiller said in RAID - the king of the storage landscape or legacy?:
@jrc said in RAID - the king of the storage landscape or legacy?:
Also, isn't RAIN basically an array of RAIDs ??
No, that would be Network RAID.
That how would you define RAIN? Wouldn't each node be a NAS of some sort, and more than likely that NAS would be configured with RAID, or am I missing something?
Also, isn't RAIN basically an array of RAIDs ??
And there, I posted a comment for the author on his article.
There is a fundamental misunderstanding from this author about why RAID exists, and that is to offer some immunity to hard drive failure, nothing more, nothing less.
Reason being, you may have protection against hardware failure but when it comes to protection against corrupt files, errors or malicious activity, you have serious vulnerabilities.
Well no shit sherlock. RAID is purely to protect you against the first bit, a decent backup scheme protects against the second, it was never conceived of or designed to do more than protect against hardware failure.
Since there is an increased stress on the array when data bits are gathered to rebuild the failed and erroneous disc, there is the potential risk of double-disk fault and read error – hence the shift from RAID to more recent data storage mechanisms.
Umm, more recent data storage mechanisms? What, like RAID10? Any "mecahnism" that involves data spread out across lots of disks with some sort of redundancy is going to be a RAID array by definition. It is an Redundant Array (or collection) of Independent Disks after all.
What an idiotic out of touch (and date) article.
@tim_g
Ahh, gotcha. Yes it does supply a service. However the company that makes the software could care less about Windows client licensing, and as a franchisee they have zero options on using this software.
And running it on a server has proven to be very complicated, especially for support as their support guys are completely gun shy when they see the SBS logo on a remote session. 99.99% of their franchises merely run the software on Windows 7 (Was XP, until earlier this year).
@tim_g said in AD Emulation on *Nix:
@jrc said in AD Emulation on *Nix:
Windows 7 VM used for their crappy industry specific software.
This would violate the Windows client licensing as you said it in the quote.
As I said it in the quote? I am not following.
Yes, I know the process, I've done it a million times with Windows servers (been an AD admin since 1998 or so). So my questions here are not about the theory of the process, I am looking for hard instructions on exactly how to do it. What commands, in what order, that kind of thing.
Umm, yeah it should be in the admin manual. Knowing it can do this does not help someone to actually do this. What are the exact steps in achieving this is what I need to know. The instructions on how to join a domain are in there, which is great, but how do I then promote it from there? This is a key step in what I need to do here.
Hmm, yes, the manual goes over it. But there are no instructions on how to use it to replace a Windows AD server (ie join the domain, then promote to DC), which is what I would have to do here.
My biggest hesitation with Nethserver is the site makes no reference to AD at all, contrast that with Zentyal, where it calls that out as the number 1 feature.
Why would that be a core feature, yet not marketed at all?
@scottalanmiller said in AD Emulation on *Nix:
NethServer
Got it. I am completely open to which way I take this. My personal preference on a distro would be Ubuntu, but it does not have to be that. I am hoping to get something that is "easy" to administer and a turnkey solution would be best I think. A nice GUI would be great.
Nethserver does not seem to say anything about AD , and it looks to do WAY more than I'd need it to, there is no need for content filtering, firewalling, VPN etc. Just AD.
@scottalanmiller said in AD Emulation on *Nix:
@jrc said in AD Emulation on *Nix:
So here is my question, how do I switch them over to a new *nix AD domain controller? Can I just join it to the current domain and promote it to a DC then remove the SBS DC? Or is this going to be way more complicated than that?
Yup, that's it. It acts just like a normal Windows 2012 R2 AD DC.
Thanks, that is what I was thinking. I guess what I really need here is a "howto" that walks me through the setup as I have never done this before. Some guides on how to administer it would be nice too.
So I finally convinced one of my clients to buy a new server, it will arrive sometime in the next few weeks. A Dell T130 server, with the 4C/8T CPU, 16Gb of RAM and 4x1Tb hardware RAID 10 (H730 controller) all wrapped up with a nice 5 year NBD hardware warranty.
Right, so I plan on axing their current SBS server setup and go for a bunch of smaller Linux VMs, one for DNS/DHCP, one as a fileserver, and one as an AD server (to be used mostly for authentication) and then a single Windows 7 VM used for their crappy industry specific software.
Currently they have 6 Windows 7 clients joined to their AD domain, and apart from auth and filestorage they do not really use too much in the way of AD services.
So here is my question, how do I switch them over to a new *nix AD domain controller? Can I just join it to the current domain and promote it to a DC then remove the SBS DC? Or is this going to be way more complicated than that?