Ste Packaging

Prior to the 1.1.3 firmware, everything was installed as, and ran as root. Following good UNIX practices, I installed apps with the following permissions: 755 for directories and executable files; 644 for all else. I held developer’s to this standard, too.

Now, with 1.1.3, we have multiple, competing, dissimilar jailbreak methods. Owner and group settings are not consistent between them, nor do they behave the same. This is causing havoc for app developers and me. Some examples:

“Nate’s” jailbreak:

• /var/mobile is a symbolic link to /var/root, which is owner:group root:wheel
• Files installed under /var/mobile by Installer.app are created root:wheel
• If you run “id” as mobile, you get: uid 0 (root), gid 0 (wheel), groups 0 (wheel)
• Applications run as root

ziphone jailbreak:

• /var/root is root:wheel
• /var/mobile is mobile:wheel
• Files installed under /var/mobile by Installer.app are created root:wheel
• If you run “id” as mobile, you get: uid 501 (mobile), gid 501 (mobile), groups (501)
• Applications run as mobile

“Official” jailbreak:

• /var/root is root:wheel
• /var/mobile is mobile:mobile
• Files installed under /var/mobile  by Installer.app are created root:mobile
• If you run “id” as mobile, you get: uid 501 (mobile), gid 501 (mobile), groups (501)
• Applications run as mobile

Problem arise, as neither application developers, nor I, know which jailbreak method a user has chosen to use.

With “Nate’s” jailbreak method, the 755/644 permissions were still fine, as everything was owned by, and running as, root.

Then, to support the  “Official” jailbreak method, I had to change the permissions on files and directories I installed under /var/mobile to 775/664. The files were owned by root and couldn’t be written to by mobile. However, since their group ownership was mobile, I was able to get things working by allowing group write.

Now along comes ziphone. Files created by Installer.app under /var/mobile are owned by root and their group is wheel, but the app’s owner and group when run are both mobile so even 775/664 won’t allow an app to write. Now I am forced to set those files and directories to 777/666 in order for things to work correctly.

So, even though Apple is trying to create privilege separation between the root and mobile accounts, I have to throw out all separation when it comes to what can write where, when it comes to anything under /var/mobile that I install via installer.app, if the app must write there.

This issue does not arise, however, for files and directories that an app creates under /var/mobile itself. That’s because the app’s running as mobile and creates the files and directories with the whatever uid/gid mobile has under that jailbreak.

Jailbreak developers need to  standardize on what the correct uid/gid is for the mobile account and what account apps run as. Installer.app needs to make sure that when it creates files under an account, they they can actually be read by and written to by, that account.

Unfortunately, so many people have used the various jailbreaks that I can’t stand my ground against users and developers and say “X jailbreak is the correct one, and the only one I will support.”, because 1) I no longer know which is correct (does anyone? What’s your proof?) and 2) even if I did, users and developers would be in an uproar if I refused to make it work for everyone, when I clearly can, just because it’s not the right way to do it.

So, I’m left with the distasteful task of installing everything under /var/root or /var/mobile with world read/write.

Someone please fix this mess.

-ste

As you may know, I now have sponsors who are paying for the servers and bandwidth needed to keep the site running. Without them, the site would go away. They are paying a lot of money to provide this service to you, and they have requested acknowledgment of this, which I think is fair.

What I have done to accommodate that request, works, but not optimally. If you open your Installer.app, and go into any category, you will see that I added mention of the bandwidth sponsor to the start of every package’s description. In Category view, it kinda ruins any chance of seeing the first part of the package’s actual description. You may wonder why I didn’t add it to the end of the description. If I had, it would have been cut off, as the Description field is fixed length. Unfortunately, the way I have done it not only doesn’t work, in Category view, but it also robs the developers of precious space in the Description field.

I have proposed, to Nullriver, that they add another field to the package detail page. It would be called Sponsor and be located just under the Contact field and before the Description field. It would be a static display field, just like the Name field - pressing it would do nothing. Here’s a mock up of what it would look like:

This is meant to provide an unobtrusive acknowledgment of the folks who are paying the bills and a way to get their URL in front of you, in hopes that you’ll check them out. However, Nullriver has objected to this. It’s their position that this is nothing but advertising SPAM, and has no business in Installer.app. I tried to point out to them that without acknowledgment, there will be no sponsors. With no sponsors, there will be no big sites. No big sites makes it harder for people to get packages. No packages means no Installer.app. So, I suggested that I blog about it and see what you, the users and developers, think of this idea. Nullriver thought that would be an excellent idea.

Please leave your thoughts in the comments section. We look forward to hearing what you think of this.

-ste

UPDATE (2008-02-12 7:24 PM): I forgot to mention that this proposed field would be optional, in the XML file, like the “More Info” field is. If a site didn’t need to use it, they could omit it. Additionally, since it’s another point of view worth considering, I’d like to point out that two developers have told me that they object to any sponsor tag on their applications. They said, and I’m paraphrasing, here, “We donated to you and we don’t think it’s fair to have another company’s name on our package’s detail page.” My response, thus far, has been that developers who donate to me are donating for the work *I* do. Things like: cleaning up what they send me and making packages out of it; writing the XML plist files; setting up and maintaining the servers; setting up and maintaining the repository; setting up and maintaining this blog, etc. You get the idea. They are paying for my time and effort, in my opinion. The sponsors, on the other hand, are paying for the servers and the bandwidth required for the users to get access to, and download, the developer’s packages. The developers aren’t paying them to do that - no one is paying them to do that. Therefore, I think it *is* fair that they be afforded recognition on the detail pages of the apps that their hard-earned dollars are making available to everyone. -ste

UPDATE (2008-02-13 12:20 PM): Keep those comments coming in - they are all interesting and food for thought. Some people have suggested that “Sponsor” might be confusing, regarding just what it is that is being sponsored and suggested changes might be “Bandwidth” or “Hosting”. Personally, I like that idea, as it’s much clearer what is being provided. Someone suggested moving it to the “Source” section. I’m not sure if they meant the “Source” section at the bottom of every package detail page (did you even know that if you scroll that page up, that there is a “Source” section there?), or if they meant adding it to each source’s detail page found by going to Installer.app’s “Sources” page and pressing on a source’s entry. In any case, I don’t think either is the right place, for a couple of reasons: 1) no one will see them there - it’s that simple, and 2) while the argument can be, and has been, made that they are sponsoring the repository, not the developers, I think that is not entirely correct. They *are* sponsoring the developers, in that they are directly providing the servers and bandwidth those developer’s need for their users to get access to and to download their packages. The truth is, they are providing the service to both the repository *and* the developer’s. -ste

While my site is having issues (which I’m working hard to resolve), you will get told that package downloads have failed, for at least some of my packages.

The package still remains in the new Installer.app queue, however, which causes problems when you try to download packages from other places.

The fix, I’m told, is to clear your queue, in Installer.app, before trying to download something from another repository than mine.

-ste

Alert - Please Read - Very Important - Pass This On

The release of the 1.1.3 firmware has caused a ton of headaches for developers and package maintainers. Many packages store media and preferences under /var/root/Media and /var/root/Library. With the release of 1.1.3, most packages will now need to store that stuff under /var/mobile/Media and /var/mobile/Library.

For developers, they have to write their apps to be firmware version aware, so that they can read/write from the correct location, depending on what firmware they are running on. For packagers, we have to install/uninstall that stuff from the right place, depending on the firmware.

It’s a nightmare.

Nullriver has released the full 3.0 version - no beta any more - of Installer.app. This release allows packagers to install the stuff mentioned above into ~/Media and ~/Library and Installer.app will put it in the right place, based on the firmware of the device.

This version of Installer.app also provides packagers with the ability to check how much free space is available, before installing, so that we don’t fill up the root partition any more. It also adds features that will help in migrating applications out of /Applications to other locations. There is more - this release is really chock full of stuff to make life easier for all of us.

It is imperative that you upgrade to Installer.app 3.0 as soon as possible. By that, I mean NOW. Right now, today. I am going to start releasing package updates today that will rely on the new features. They will not install correctly on older releases of Installer.app. If you run into any trouble and find you need to manually download and install Installer.app, get it from here, which always points to the latest version. Other repositories will start using these new features shortly, too, so it really is in your best interest to upgrade right this minute. If you do not, and you have an issue installing any of my packages, my response will be “please upgrade, try again, and only come back if you still have a problem”.

To prevent this kind of chicken-and-egg issue in the future, one new feature in this release is the ability for the package maintainer to specify a minimum Installer.app version required for the package to install. Unfortunately, this time, we can’t really use it, because the older Installer.apps don’t understand that feature.

For a full listing of changes in this release of Installer.app, please see the “Featured” page in your current Installer.app.

-ste

It seems to be working pretty good for the most part. There have only been a couple of problem reports. As I write this, it’s been 11 1/2 hours since the caching system went into effect when Nullriver updated the “Community Sources” package for me. Since then, 200 cache servers around the world have picked up and started serving the XML file, and the number is climbing all the time. Much better than just my one server serving it!

Already, I am seeing the access.log scroll by slower as I continually tail it. I even see the occasional brief pause in the output - something I haven’t seen in months. So, it looks like the caches are starting to take away some of the load and traffic, as hoped.

If you haven’t already updated your “Community Sources” package to the latest version, please do so. The faster people do, the faster the load on my server goes down. Thanks!

-ste