Re: PB 1.1.1 pi not redirecting traffic

Ok, let me start with something less technical.
First of all, I want to apologize for insulting & being unprofessional with you. When I read you post above, you hit me on the right toe at the right mood and point in time. So, please excuse me.

Quote

My point is I changed all them and it still messing up, is there away to remove the redirect and recreation full stop?

Then something must be missing. Remember, there are a lots of places where the browser cache is playing tricks! Assuming that there is no bug with copying the content folder, you have the following places where the hostname is relevant:

- /opt/piratebox/www/index.html
- /opt/piratebox/www/redirect.html
- /opt/piratebox/www_content/index.html (only the iframe)

I used

grep piratebox.lan /opt/piratebox/ -R

to find the occurrences in the source.

Yes you can disable the redirect, with puuting a # in /opt/piratebox/conf/lighttpd/lighttpd.con in front of the line

server.error-handler-404 = "/redirect.html"

Quote

Your path to make it N00B proof as in some places make it more complex, it redirects back to piratebox.lan even when you have edited the files all the tuts on here show you, it will go to the new domain if you enter it, but if you go to another domain it will still go to piratebox, I liked PB's set up part from this really, I been able to install and set up everything on the pi manually part from the fake DNS and domain name what I would love,

As I said, you might be tricked by your browser cache. It is possible that the change hostname option of the install_piratebox.sh has a bug and does not update the index.html (which are linked together via the filesystem). You might check www/index.html and redirect.html if both contain your new domain name after the usage of the install_piratebox.sh hostname option. If index.html is not updated in the same step, please open an issue on [github.com] including a copy&paste of the steps you did and a copy of the two files (copy & paste is enough).

I think, that you misunderstand how the PirateBox work:

- The DNS redirect does only resolve all dns requests with the local IP address of the box. There is no change in the requested hostname.
- The DNS redirect is supported by a firewall rule, which redirects other requested DNS Servers to the local machine (like a static entry of googles DNS Server 8.8.8.8)
- The 404 error handler and the default domain index page ./index.html are forwarding to the displayed domain into the /content folder. The 404 handler is playing tricks with you, when you do a mistake in your website editing! This behavior might be changed if we make the 404 handler only active for hostnames un-equal your box name (good idea, I'll take a note of that one).
- The webserver has additional configurations to create fake answers to mobile clients on Android and iOS, which unlock the normal browser (especially on iOS, which drops to mobile network if the wifi is not sufficient)

If there are points in the configuration, which do revert back with every reboot, something is going totally wrong.

Quote

The Web host side is VERY confusing and makes no sense, I been dealing with web hosting for about 10 years on both platforms and this is the only one that's ever confused the hell out of me, I can't even follow the default setting for that hosting platform as you edited enough for it to make no sense to every other source online.

Once again I can see this is to create one fix need but its locking out so many good ideas for the IMG, I not going to stop learning or following the project but in places it does become over complex.

I see you point, but I can also see, that you only see the top of the ice.

Let me explain why it is designed as it is and how it changed over time:

When I joined into the project back in Jan 2011, David has only a small howto of 20 single commands to setup a PirateBox out of an OpenWrt router together with a Seagate dockstar. A lot of people showed interest and it grew popularity quickly. It also was pretty clear, that the main audience is not a hacker but people with less or no skill.
In summer 2011, a German hacker made a new version which integrated the dockstar together with the OpenWrt. This solution was a hardly hacked version which enables OpenWrt based routers with only 4MB(or 8MB) flash disk to run PirateBox... which is nearly nothing in terms of an operating system.
At this time, I already created a bundle of scripts designed to run on Debian and bring the same functionality to notebooks but not as an invasive change. My focus was and is to create a set of scripts, which are beside the system's configuration- the that you can turn on & off piratebox on you notebook, if you need it.
The hacker dropped the project pretty quickly and based on this hack a lot of people ran into A LOT OF issues. So I took over the stuff around Jan 2012 and started to merge both worlds to the same code base.
Later the first RaspberryPi came out and beside of maintaining & improving the OpenWrt part, I needed to get something working on the RPi.. It was never 100 % perfect (below more).

Today, everything in opt/piratebox are 95% identical between both plattforms. Over the years, I aligned the OpenWrt packages to work like a normal OpenWrt package and do not work with ugly package management hacks. The installation problems are dropped to an absolute minimum and the installation is as easy as never been before. The differences are mostly file structure and network/wifi configuration (in OpenWrt done by OS). Everything about using the box and alot of the customizing should be the same.
But, due to the fact, that on OpenWrt is literately no space for anything, it is needed to move a lot of things to different places. The folder "share" is designed to be located directly on a FAT32 USB Stick. This is why "Shared" and "board" inside www are pointed to that folder with hard symbolic links. On OpenWrt, nearly all content is located on the USB stick.. but not only because of space, but it is the most comfortable way for all the non technicians to add/remove content on the box.
Not only the disk space is limited on these small devices. We are talking about CPUs running at 400MHz. This is the reason why I and other put effort in it to avoid dynamic rendered pages. For example "dokuwiki" would do an amazing job for having a dynamic web page to add you content... but it consumes too much power.
So, This is the reason why we do not have a directory listing like h5ai, but this text base version with HEADER.txt and README.txt (in fact you need to adjust the src folder and then remove both files from you shared folder, or run a script to force an overwrite). I still have the fear not being able to run at those tiny device because of a too complex script.

The next big question is about that nasty iframe for the upload. Why do we use it? Because in summary a PHP upload script does not run 100% well on these devices. On lighttpd, the following thing is happening during a file upload:

  Browser - uploads ---> Lighttpd ; Caches the complete file (on USB)
  if file complete,   lighttpd --- transfers via IO read  --> CGI
  CGI receives ---> writes to disk (on USB)

So, the system ends up with twice or triple IO for reading/writing the uploaded file on the same device, while droopy just places the file directly in the upload folder while getting the data over network.

I started to work on a PHP uploader, which uses the /tmp folder (RAM) on OpenWrt, but this always have the risk of crashing the operating system because of OOM.

Quote

this means you can use one domain name setting in the config file and using php can include all changes across all the pages you include the redirects, but using php should also remove the need for redirects on the uploader and things like this.

As described above, PHP does not solve all the problems. I want to avoid dynamically pages as much as possible to keep it as fast as possible. Adjusting the webpage for customizing is done only by one person (at the creation)... but showing the content is done by each page access. So, we should try to save as much CPU cycles as possible, which means no PHP entry page. Especially not for the redirect, because this is hit far more often.

As much as I decrease the static pre-configuration, I increase the load on the CPU. This creates trouble for the smaller devices and consumes battery for the larger ones. I know, that it is not the easiest options.

Beside of the resource related part of the design choices, there are also much lines of code, which simply avoid pitfalls. There are a pile of things which make the installation as simple as possible.. but we never intended and will never intend to remove the need of the CLI completely. The reason why is, that people should start to learn with it. In fact, this is one of the feedback we always get: "Yes, with PirateBox I started to learn the command line".

Things, which look awkward, but we did to support noobs:

- HEADER.txt and README.txt are always copied if missing. This avoids the issue if somebody deletes it on the USB and directory listing does not work anymore.
- A copy of the content folder is located on the USB stick to enable easier editing of your website on you local PC. This worked out for LibraryBox (sister project) pretty well. Before anybody needs to reflash his box, just remove the folder from your USB stick and you get a fresh copy.
- (OpenWrt) completely automagic installation and with 1.1 auto-reflash
- A lot of helper scripts which avoid using vi (mostly helpful on OpenWrt)

Today, I am glad that some other developers (stylesuxx & TheExpertNoob) joined in working for the RPi. Both sharpened the image for the RPi and the main functions are pretty well done. We are carrying around some legacy stuff, that is true and I am aware of that. For example, I already started to modularize the lighttpd configuration.
It is planned to ship PirateBox 1.2 with a pre-activated PHP if are sure to not open up security issues with that. We want to include h5ai directory listing as an option with 1.2, too.

For the RPi image, we chose Archlinux, because there is a ton of wiki documentation on their webpage. In addition, Archlinux has a very small footprint compared to the newer raspbian OS images which come with a desktop pre-installed :-(

I am working on several things (like lifting PirateBox to a newer OpenWrt version). In fact, it feels like sometimes, I am the only one pushing the project and answering questions. This also means a low motivation for pushing after 6 years now and my piratebox free time is split up between "answering forum", "documenting" or "writing code". Mostly I am answering questions...
---

According to your issues, as I said, it sounds to me, there is a bug with the content folder, which should not be.
About your question for the DNS redirect thing

   dns_redirect="/#/192.168.1.1"

Cheers
Matthias