Adventures with Windows 10: part 1

Microsoft announced that free upgrades to Windows 10 would end on July 29, 2016. I bought a full copy of Windows 7 to load onto a VirtualBox Virtual Machine several years ago, but never got around to installing it. I realized that this week would be a good time to get that project started and finished.

A while back, I created a ISO file of the Windows 7 installer DVD. I know that my current laptop does not have an optical drive, but the older one (the one with the failing trackpad) does. I suspect I bought the installer when I had the older laptop, but I also knew that I would need an ISO, if not for a new laptop, then for the desktop, which also does not come with an optical drive. (Weird.)

I created a new VirtualBox Virtual Machine to handle Windows 7. I remember I created a virtual optical drive in the virtual machine settings and attached the ISO to that virtual drive. Everything looks ready. Let’s start. Immediately, I get a message saying “Failed. No bootable medium found.”

I aborted and checked the settings again. There was a google search that suggested I hit the F12 key during boot up. That may have solved some issues, if I had tried it. I knew I needed an external optical drive any way, in case I sell or destroy the old laptop, so I drive down to the local Apple store and buy an overpriced optical drive.

I come back home and attach it to the new laptop. I can see the Windows 7 optical disk in the finder. I misunderstand how to load it in the Virtual Machine settings and end up starting the installer from the ISO. I know because if the installer were using the disk, I should have heard spinning sounds from the optical drive, which I did not.

It looks like Windows 7 is installing this time. I know it’s supposed to reboot to finish installation. What slips from my mind is that the second time, it’s supposed to reboot from the hard drive, not the ISO / optical drive. I keep interrupting the boot process by manually booting from the optical drive. It turns out that I installed several copies of Windows 7 into the virtual hard drive until I ran out of space.

I can see this is not working, so I start over with a fresh Virtual Machine. I decide not to add a virtual hard drive after realizing that the link to an optical drive already existed. When I start the blank windows machine this time, I was asked to pick a bootable drive. I was given the option of the drive with the Windows installer or the ISO (?). I pick the drive and go through the installation again, along with my extra second installation from the optical drive after reboot.

I read a bit online. (Google is your friend.) At this point, I realize that I need to let the reboot work without interference from me. I wipe out the Windows partitions created by the Windows installer and start over.

Finally, the Windows 7 installer works. I have a running Windows 7 instance running in VirtualBox. Next steps:

  • upgrade to Windows 10 for free – nope, 99% freeze. See next post.
  • load an anti-virus application – I’ve done research on free AV
  • load all other windows updates – nope
  • install Firefox and Chrome – eventually

All of that is for another time.

Advertisements

Catching up with Python

I always forget that major software upgrades in OS X reset permissions in /usr/local. When I checked my brew install, I saw that message. I played around with write permissions only, but in the end, did what brew recommended and reset the permissions as described. That allowed me to update brew and move on to the next task: updating Python3.

I was not as far back as I expected. I was sitting on Python 3.4. The upgrades went smoothly and I’m back to Python 3.5.1. I thought I had modules installed, but I’m not getting any list of local modules installed. It’s very possible, since I never did much with on the desktop. That will be the next task.

Resetting after El Cap install

I have some more free time, so I decided to reset my El Capitan system as a development machine again.

I bought my license for BBEdit 11.5, so I installed that. I’ve used Visual Studio Code at work. I like how the window can take over the entire screen, but I don’t like how only three tabs for files are allowed per window. If you need more files open, you need to open another window. It seems weird. I’ve used TextMate. Again, I like how tabs are used to show files instead of the list used by BBEdit. I’m used to BBEdit’s quirks, so I’ll go with that for the moment

I need to reload Apache. I use the standard setup:

sudo apachectl start

However, Apache would not start this time. Running

apachectl configtest

shows an error with something called LockFile.

After some searches with StackExchange, I find out that LockFile is an Apache directive active for Apache <= 2.2. El Capitan runs Apache 2.4.16. Comment out the section that includes the LockFile directive and restart Apache. Localhost is working again.

I’m using the instructions in this page to activate Apache and PHP. phptest.php works after restarting, but I have the PHP timezone problem again. I had to copy a php.ini file from the included php.ini.default, set the timezone to “America/Los_Angeles” and restart Apache. Problem solved. More stuff coming soon.

installed intl extension for PHP

I’m getting ready to install CakePHP 3.1.3 on my laptop. I discovered that I needed the intl PHP extension installed as a requirement for CakePHP. I tracked down several web pages with instructions and I decided to use this one, considering I had good luck with the page the last time I needed to install the intl extension. The page is for OS X Mavericks. I found no significant changes when I followed along for my Yosemite laptop. The only real change that I saw was that there was a new version of the ICU installer (56.1 as opposed to 52.1 described on the page).

I was surprised that I needed to install PECL and PEAR, considering that I don’t use PEAR that much any more. PEAR did not give me trouble. However, pecl.php.net was down the afternoon I wanted to install the software, so I had to wait until the next morning to install it.

Like I mentioned, the ICU installation instructions are almost the same. The only difference is the updated version of ICU, 56.1. Substituting the new version into the suggested Terminal commands went well

I thought I already had AutoConf installed, from what I saw in some libraries in /usr/local, but I decided to install it again to be sure. I had no trouble with it.

PECL gave me no trouble when I wanted to install the intl extension. Somehow, my php.ini file had been updated with the extension command pointing to intl.so. I thought that was odd, but I let it go. When I checked phpinfo(), there was a new entry for the intl extension. Very nice.

odd home-brew issue with permissions,

I was going to update files installed through home brew and I noticed an odd error message:

Error: unable to unlink old ‘share/man/man1/brew.1’ (Permission denied)

or something like that. That’s never happened before. /usr/local should not have a permissions problem, unless MySQL is involved somehow. (B’). I run ‘brew doctor’ on the command line and it suggests permission fixes for /usr/local/bin/, /usr/local/share, /usr/local/share/man and /usr/local/share/man/man (?). Why did this happen?

I know that “rootless” access is being enabled in OS X 10.11, El Capitan. The idea is this “System Integrity Protection” will make it difficult for malware to install itself in /System, /bin, /sbin, and /usr. However, /usr/local was supposed to be left alone. Also, I’m running Yosemite, not El Cap. Even so, I need to run my updates, so I run the following in Terminal

sudo chown -R “$USER”:admin /usr/local/bin

sudo chown -R “$USER”:admin /usr/local/share

When I run “brew update” again, my system is ready for brewing.

From what I can tell, it looks like folder permissions may be reset during each system software update. I can’t confirm it, but it makes sense. If I had problems after a system update, I would run the Disk Utility and have it repair permissions. Usually, whatever problem I had would go away. It looks like OS X wants to be helpful, but also interferes with the way I have things set up. I’ll make it work.

reloading files … not fun

My workstation has a weird short circuit somewhere that has to be tracked down at the help desk. While I wait, I’ve tried to install my work on the department laptop. It has not been easy.

Luckily I pushed copies of what I was working into repositories for off-site storage. Unfortunately, those repositories were slightly out of date. I did not lose anything from the database archives, from what I can tell. The CakePHP 3 repo is about two weeks out of date. I convinced myself it was OK, since I spent two weeks trying to solve a dead end regarding JQuery, AJAX and calls back to the original CakePHP action. It should be easy, but I have not been able to track down the answer yet.

I cloned the archive repository locally and reloaded that SQL into the local copy of MySQL. That went fine, with some minor issues. You can’t load a table with foreign keys until after those related tables are loaded first. (Of course.) If the file is too big to load through phpMyAdmin’s 2 MB file limit, zip it and try again. (That answer was staring at me all day long. Very annoying, once I found it.) Everything looks fine, so I move on to the next action.

Next, I needed to reload the CakePHP repository. Installing CakePHP is a little more involved than cloning a repository. For starters, the docs say I need Composer to install, which is not loaded on the laptop. I’m not sure why that would be needed for a repository clone, but why not? It can’t hurt, and I might need it, so I load Composer using homebrew. I found my old instructions for installing composer, but I forgot the final instruction, about ignore dependencies. I’m sure I thought it was obvious at the time, but it’s better if I remember putting it in. Finally, Composer is loaded, updated and ready to go.

Next, I remember that CakePHP needs specific PHP extensions to run properly (mbstring, openssl, and intl). The one I did not have was the intl extension. I checked my notes again and found a very good description of how to install the intl extension. That’s done, finally. I’m ready for CakePHP.

I clone the CakePHP repository. When I try to load it, it bombs. I get an error about permissions denied in the logs folder. I remember this error from another installation, so I’m confident I can track down the issue. I also notice that the vendors directory is empty. Now that I have the composer.json file, I update Composer and run it again. The vendors directory is back, but I still have the permissions problem.

While checking the vendors directory, I went to the config directory for some reason. I noticed that my config/app.php file is missing. That’s odd. The app.php file controls database access, so I’m surprised to see it’s missing. I finally get access to the Time Machine drive of the old machine and copy the latest version of that app.php file over. The permissions problem is not solved, so I decide to start from the basic installation with a test site described on the CakePHP web pages.

I stumble around, comparing user/group settings on folders between the fresh install and the Time Machine backup. Eventually, I get them set to something that looks like it works. However, the links to the CakePHP css pages are not working. I remember this again from a previous install. This has to do with apache and how it blocks access to .htaccess files (or something like that.)

I track down the section in the CakePHP documentation regarding URL rewriting, so I figure out how to set apache properly to get it to read CakePHP’s .htaccess file. While there, I find a related link that tells me exactly how to fix the logs and tmp directory. I’m almost ready, except for the part where my archives have disappeared. Somehow, they tables I loaded disappeared at some point. Very strange. This is important since I built a small website that uses CakePHP to display the data in the archive tables. Next stop. What happened to the archive tables?

quick note: Bash bug

Today’s news about a bash bug has sparked the internet equivalent of lots of people yelling about something they don’t really understand. I will admit that I don’t fully understand the bug, but I stumbled across a good explanation of the bash bug here.

UC San Diego computer security has also reviewed the infection vectors. They say that Apache modules (mod_php, mod_perl, mod_python) don’t appear to be vulnerable. However, the article linked above does say that library calls created by php functions may be vulnerable. I don’t know enough to understand how the module can be OK, but the system call going through the module is not OK. The key appears to be sending a hyperlink that opens a terminal window that then acts on the original bug. Seems like a lot of work, but it’s a hole. An easier possibility would be to attack apache systems that use CGI directly.

The installation of patches is recommended. When Apple and OS X gets patched is unknown. Red Hat rolled out an incomplete patch earlier today. It’s been reviewed and a better patch is expected soon.