New beginnings

Since I truly last posted a lot has changed. I moved to Houston, TX, USA (from MI) for a position as a Linux System Administrator. As of this week I've been moved to the programming department in my company, coding Perl. I'm also an elected moderator on StackExchange's Unix & Linux. Of course there's always updates to my CPAN dists.

Adding and Deleting subdomains with Plesk on the Command Line

Plesk has the disadvantage that everything is done through the
database. So we can't just modify Bind's Zone files.

To add an A record of a subdomain you have to do the following:

/usr/local/psa/bin/dns -a domain.tld -a subdomain -ip 127.0.0.1

the first -a is for add to zone which is why it must specify the top
level domen, the second is for A record, and must not contain the full
domain only the subdomain. If you use the full domain
subdomain.domain.tld you will end up with a record like
subdomain.domain.tld.domain.tld because plesk does not allow you to
terminate with a .. Thank you plesk for a shitty interface. The record
this create's looks like

subdomain.domain.tld. IN A 127.0.0.1

To delete this record you would use the following

/usr/local/psa/bin/dns -d domain.tld -a subdomain -ip 127.0.0.1

you'll note that it's the exact same thing except you replace the
first -a which is for add, with -d for delete.

Writing a simple Dist::Zilla::Tester test

Hopefully, someone will use the blog post to write an actual doc patch, seeing as how this is undocumented.

I finally wrote A test for DZP::OurPkgVersion with the help of CJM. So I figure it's best to share the knowledge imparted upon me to all those who are writing plugins without tests.

Before we get started I'm going to advise that this test will only check the output that dzil built, if you need it to test anything more sophisticated, you'll have to learn more.

First you'll want to create a corpus repo like /corpus/MyDZTRepo with a basic minimal repo. This repo is simply a repo that you are using to test your plugin against, to make sure it works right. You put it in corpus so that if you have tests that you have to check in your corpus, those tests themselves aren't run when the test suite is run. The dist.ini doesn't need to contain anymore than the basic stuff needed to build. You .pm files need not have anymore data than what you're going to need to make your dzil plugin do its job. In the case of DZP::OurPkgVersion I only needed to test that the output found the # VERSION string correctly in a couple of scenario's. So that meant having # VERSION in the .pm's and [OurPkgVersion] in the dist.ini.






First DZT (Dist::Zilla::Tester) doesn't provide any tests of its own so you still need to use Test::More or some other testing framework. Next you need to initialize the tester object by telling it where the root of your corpus repo is. After that, unless you need to do other work, you can run $tzil->build so that the build is run.

So now lets slurp a file into memory so we can check to see if it was built right. You'll want to look in 'build/*' as the basic root of the build directory. So 'build/t/test1.t' if you need to slurp a test.



Now that we've pulled our build files into memory lets code up what the result should be. We can just do this with a simple heredoc, obviously you can do it another way.



Now that we've gotten that, all we have to do is compare the file that we expect dzil to output and the file that dzil actually built. This is just standard Test::More



Now let's take a look at it all together.


Pretty simple huh? Hope this means more dzil modules getting tested now. Including more of mine.

Making Secure Recoverable Passwords ( part 3 )

If you haven't read Part 1 please do so.

Although the criticism of Part 2 should be taken with a grain of XKCD Salt, and even the primary plaintiff admitted that it would take him 2 months to crack the final salted sha512. Usually your attacker shouldn't have your shadow file, and having stored them as anything less is just plain not secure. I will acknowledge it has some merit.

Doing a base64 transformation on hex only digits is a bad, idea, and does not have nearly enough possible combinations. Nothing is going to be more secure than random, but random isn't really recoverable, if you lose it. That's why I do some kind of transformation.

I believe that somewhere someone suggested that it would be better to convert from the binary digest into base64 as it would be more random than from hex. I believe this is accurate, but the method suggested was in Perl, which is kind of messy, and more importantly hard to remember. So I asked, on unix.stackexchange.com, how I could do this on the command line. Here's the answer I decided to accept:

echo -n `date` | openssl dgst -binary -sha512 | base64

Remember you should slightly modify the result in a way that you can remember in your head to make it random, and probably use something in place of the "date" command, since it's not reproduce-able.

Again: this is not meant to be as secure as random passwords, just secure enough compared to non random alternatives.

Ubuntu isn't Linux, What's a Beginner anyways?

Today Joel Spolsky announced The results of the poll of whether ubuntu SE and unix SE would be merged, they won't. In short the Unix community was in favor of it but the Ubuntu community was not. Joel had this to say:

So, Ubuntu, Linux, I get it, it’s clearly not the same thing. If you love Ubuntu, we have a site for you. If you love Linux and Unix, we have a site for you. A Stack Exchange can’t work without a community that loves a subject, and love is very… specific. Fighting human nature is hard: the factionalism and fork-happiness of the Unix world has been a hallmark of that community ever since BSD vs. System V, and Stack Exchange can no more bridge that gap than we can unite the Judean resistance.

I am horribly disappointed in this decision, this factionalism doesn't help the cause, this set's precedence that it's ok in the StackExchange community to be a separatist. Arch Linux's bash must not be the same as Ubuntu's or Fedora's, and of course they've made so many changes to upstream Gnome as to be unrecognizable as such.

The main argument in favor of this separatist movement is that Ubuntu is for beginners, if that's so then why isn't it beginner.unix SE? What's a beginner anyways?

I'd dare wager that 99.999% (POOMA) of all Linux users are windows Power users, veterans, and refugees. So what's a beginner? someone that doesn't know what Firefox is? No they probably do. Maybe they don't know where it is in the menu? I can see that... but I don't see how that can't be answered with a Screenshot and a Ubuntu tag on Unix SE. Maybe it's someone who doesn't know how to use the CLI? Well where do you define beginner from advanced? I realize someone reading there first shell programming Tut/Book/etc is a beginner, but are they no longer a beginner after that? how do you know you're not a beginner anymore? When you choose to move beyond Ubuntu? If I've been using Linux for 5 years and I choose to move to FreeBSD am I a Beginner?

Why is that the answer to a beginner from an advanced user isn't welcome? Is it good that beginner are exclusively answering other beginner questions?

In other news it looks like I may become a moderator ( temporary at least ) for unix SE.

I need a new favorite OSI license or Why I don't like the GPL anymore

I don't like the GPL anymore after the WordPress Theme fiasco. I don't like the idea that a theme, plugin, addon, extension, whatever is 'derived' from the thing it's adding on to and thus must also be GPL.

If I build a deck onto the back of my house is that deck derived from my house? No! if I take the blueprints of my house and build another one that's 80% like it is that house derived from my house? yes. If I offer a painting service to paint houses and I offer people preexisting color schemes are those schemes derived from their house? should the manufacturer/contractor (whatever) be able to tell me I can't do that, or that I have to share my colorschemes (and how I mix my paint) with him? How STUPID, IMO. But that's what the GPL does, you can't help other people addon to their house without sharing it with the house builder.

Now I'm all for sharing source code back, and I think if you modify OSS you should have to give your source back. But if you don't modify it and you are just using the the public API, why should you have to give all of your code up for that? or more importantly why shouldn't be you be able to choose your own OSI approved license? I mean what if I have a GPL library, a Artistic Library and a BSD library I want to use to build an application, which has an API, must be GPL and so must everyone's apps that add to it. No you may not make a DWTFYWWI plugin, no you may not make a BSD plugin, no you may not release that code into the public domain, because the GPL says so, and I used a library that made me use it.

Well ya know what? I'm not going to use the GPL from now on. I need to find a new license that fits my needs (and will not be toxic to others).

Desire #1. He who modifies my code, and distributes it, must share his code (with me).
Desire #2. He who wants to use my API may do so (so long as he doesn't modify it)
Desire #3. He who wants to copy my code must share it, and any changes.
Desire #4. Some patent protection would be nice
Desire #5. letting users outside your organization utilize it counts as distribution (a'la AGPL)

I think the LGPL fits this bill, except for #5.

seriously why is it that you could optimize the internals of wordpress and make your own hosted blogging platform and you wouldn't have to share the changes at all... but with a theme you do...

Are there any other licenses I should consider or considerations I should make?

(honestly you don't have to agree with me about not liking the GPL here, this is just me)

Some Stack Exchange site's I'd like to see come to fruition

• Unix & Linux: I think it'd be more used than Super User and ServerFault for some questions.
• Outer Join: A place to ask questions about databases and queries
• User Interface: because this is something we could all do better with.

Please consider following/committing. esp the unix/linux one (since I don't think Ubuntu should get to have its own, while leaving the rest of us in the cold.)

If you can't beat them, join them

I have been heavily criticized for criticizing, critiquing, and complaining about lack of quality in open source projects. I have done these things because I care, generally because I care about that specific project, or Open Source (or whatever I'm talking about) in general. I've been attacked, insulted, and sworn at. I've recently come to the realization that the community support that behavior, to the point that they won't stand up against those doing it. It is a very cliquish and tribal community, if you're in the in crowd you can do or say what you want, if not you'll be ostracized. I have been ostracized for years. I have decided to join the opinions of those I've been ostracized by, but also to accept my exile.

In order to discontinue my negative and inappropriate behavior, I have to stop caring. I choose now to not care about helping others who cannot (or choose not?) to help themselves. I will no longer complain about the problems of some projects, even those that I can and have provided fixes to the problems for. I will no longer fix problems that do not impact me. I will no longer tell people that they are misguided, no matter how much they are. I will no longer produce anything that doesn't help me. I have to become selfish and stop caring about the problems of others.

To this end I'm discontinuing my work on Arch Linux's AUR as it doesn't help me, CPANPLUS::Dist::Arch which does most of the work, is more than capable of doing this for anyone using Arch, the packages will be orphaned. In acceptance of my exile I am removing myself from all IRC channels (though I will continue to connect) unless I have a problem, that way I do not end up causing a problem, it seems even when I have a problem and try to limit it to that I end up causing one. I am going to ask that my blog be removed from the Iron Man 'competition'. I've been told that none of the work I've done is significant anyways, and thus my loss will not be a loss at all.

I will continue working on any project that has some benefit to myself, as my time is precious and I have a life outside of Open Source. I will only do so, however, if it doesn't require me to have an opinion. There is no point in pushing for a fix that I have a workaround for already, I will simply be seen as entitled and asking too much of other peoples time.

I can't win the fight by writing patches, or by helping people by answering questions, or sharing my knowledge publicly. So I choose not to fight, I choose to accept that I am not wanted and so I will leave.

Creating new projects with dzil new and templates

Here I talked about creating a new catalyst project using a minting profile for Dist::Zilla. If you don't know how to create a minting profile read that first. I'm sure once you've tried that you'll agree that having a little bit more than the basics in a newly minted dist would be a good thing.

first we need to create our profile.ini correctly (note: if you've got [DistINI] plugin loaded you'll probably want to remove it) Now you can put any file in the subdirectory repo of your profile (if you leave out 'include_dotfiles = 1' then anything beginning with a . won't be included), and it can be a template using Text::Template. Dist::Zilla uses {{ }} for Text::Template Delimiters.

Let's start with adding a .gitignore file (if you're using git) we can create {profile}/repo/.gitignore the {{$dist->name}}* will exclude the directories and archives dzil creates on release and .build will of course ignore the .build dirctory.

Now for a more complex issue, creating a Changes file that has the the {{$NEXT}} variable in it to insert the date and such on build. Obviously you can format your Changes file however you want.

Now we want to create a much more complicated dist.ini All of the stuff between the first set of {{ }} is boilerplate mostly taken from the DistINI plugin so that we can use our settings from our config.ini, I really wish there were some convenience accessors for this. I also wish we had an arbitrary stash we could use in config.ini so I wouldn't have had to hardcode my username in this. I think it's all fairly self explanatory beyond that. Of course you can set up your dist.ini anyway you want. Also if you use this format you have to have your module's repo name on GitHub in camel case like it is on CPAN.

Don't Use Big Words

Next time, in promulgating your esoteric cogitations, or articulating your superficial sentimentalities and amicable, philosophical or psychological observations, beware of platitudinous ponderosity. Let your conversational communications possess a clarified conciseness, a compacted comprehensibleness, coalescent consistency, and a concatenated cogency. Eschew all conglomerations of flatulent garrulity, jejune babblement, and asinine affectations.

Let your extemporaneous descantings and unpremeditated expatiations have intelligibility and veracious vivacity, without rodomontade or thrasonical bombast. Sedulously avoid all polysyllabic profundity, pompous prolixity, psittaceous vacuity ventriloquial verbosity, and vaniloquent vapidity. Shun double-entendres, prurient jocosity, and pestiferous profanity, obscurant or apparent!!

** ** In other words, talk plainly, briefly, naturally, sensibly, truthfully, purely. Keep from slang; don't put on airs; say what you mean; mean what you say. And, don't use big words!"

I don't know where this came from originally, but I should also say... cut the technical jargon to a minimum. Not everyone knows everything you do and even if they know all the words laymans terms may be a better way of explaining it. Give an analogy, if they don't get it; Reduce it to the simplest possible terms.

P.S. I pissed someone off because I told them it wasn't my understanding that was the problem it was there ability to explain things simply, and then gave them a link to this. I did eventually get why X was a good thing in spite of the overcomplicated explanations.