Within the last few weeks I decided to take the venture of moving my host provider from one web hosting company to another. At the same time I decided that I wanted to do Windows hosting going forward so that I could host ASP.NET applications. I figured this would be easier since I know more of C# and .NET than I do PHP and the linux web hosting technologies. Boy, was I wrong…
So the first issue was with the domains. Normally when you transfer domains from one provider to another it can take up to 7 days. For some reason one of my domains transferred in what felt like hours. Instead of a week I received the email that the domain transferred in a day or two. Although I received an email that the domain transferred and it showed on the new provider, the old provider also still displayed the domain. Thus when I deployed my new website and all the files to the new provider it would sometimes display the old provider. Awesome times…
Once that was straightened out my new site starting throwing a 403 – Forbidden error anytime that I browsed to the page. The 403 error seemed consistent but then when I deployed my solution would work and I could browse to the pages without issue for a few minutes until the 403 error would resurface. Contacting the host provider the 403 error appeared to be caused by settings on the server. This lead the provider to ask me to change several things in my web.config file as well. This included code to add the following:
This seemed like a bit of overkill. This also did not fix the issue either. Instead the error continued and given that this didn’t seem to work, I reviewed other solutions and suggestions made online and replaced the above with:
Although this code seemed to directly address the issue, it didn’t work either.
The issue at this point was diagnosed to be with ASP.NET and more specifically the MVC routing within. None of the views were being properly executed and the controllers were never being reached. No matter what I did the error would not cease as every time I deployed it worked for a while and then around 30 minutes later it would go back to 403 – Forbidden.
The issue turned out to be an issue with the precompile setting on the publish settings dialog. Below is the settings dialog.
The second checkbox was causing the issue. For some reason checking this box would cause a security issue that would prevent the MVC Routing for executing properly.
Maybe next time I will realize the shortcut isn’t worth it…
In working with apprentices new to Git and really new to source control in general, I have come across a couple cases where someone will have a repository defined within a repository. In these cases the parent repository is not tracking the files within the subdirectory and there appears to be nothing that can be done to resolve this. To paint a better picture let’s work with this example:
In this example there is a .git directory within both the project folder and the sub_project folder. Thus Git believes that these are separate repositories and in fact by design, although not correctly defined, believes that sub_project is a submodule of the project repository. I say not correctly defined since it cannot be found in a .gitmodules file. It only appears to be a submodule. We would have some work to do if we wanted it to be correctly defined. However, in the simple case we don’t want to do this and instead want to remove the repository from the subdirectory.
To fix the issue we need to delete the .git folder in the sub_project directory. We also need to remove the directory from the index of the project repository so that we may re-add the directory and be able to track the files within the sub_project directory in the project repository. To do this we can run the git rm sub_project command. Thus to fix the issue:
1. delete the .git folder from the subdirectory
2. run git rm sub_project
3. re-add the sub_project directory to the project repository
Now things should be ok and we should be able to continue using our project repository with no issues. We just need to be careful not to create repositories within the project directory unless we really want to have submodules.
In doing this again I did have to run git rm with the --cached
Talk about excitement… I was setting up the Pi for a backup server and connected one USB drive, no problem. Everything seemed to work and I was in great shape. Then I decided to add the second drive. Upon doing so, BAM! CRASH! BOOM! etc. Raspberry Pi was down for the count and was not getting up. Want to take a guess what happened?…
Well, the main piece of information I left out was that the two drives were USB powered drives and relied on the Pi for their power. WHOOPS! A raspberry pi doesn’t have enough power to provide the power to maintain two USB drives. Hence, drives attached = Pi no more…
You didn’t honestly think I gave up there right?!?
So I needed the drives connected to the Pi but an external power source for the drives to work and the Pi not to crash.
You get where this is going yet…
All you need is a powered USB hub. I picked mine up at a local best buy since I wanted it that day. If you plan ahead you can probably get a better price online if you want.
At any rate, if you have USB drives that need power from the USB they connect to and you are trying to attach them to a Pi. I highly recommend a powered USB hub.