Tune Your Guitar

Adding disk space to a graylog 1.x OVA without creating a new drive

noreply@blogger.com (Anonymous) — Fri, 02 Sep 2016 13:47:00 +0000

There are a few tutorials out there that explain how to do this by adding a new drive. Most notably:

http://docs.graylog.org/en/1.2/pages/installation/graylog_ctl.html#extend-disk-space

However, I found you can skip the hassle of a second drive by following these steps:

1. Extend Disk in VMWare

2. Parted

Run the following command

sudo parted

Then inside parted, run:

print

This will list your volumes. For me it was:

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  256MB   255MB   primary   ext2         boot
 2      257MB   21.0GB  20.7GB  extended
 5      257MB   21.0GB  20.7GB  logical                lvm

Next, inside parted, run:

resizepart
Partition number? 2
End? [21.0GB]? 50000 (to extend to 50,000mb ~50gb)

resizepart
Partition number? 5
End? [21.0GB]? 50000 (to extend to 50,000mb ~50gb)

exit

If you want, you can run print again to see the new sizes

3. lvm

Launch LVM:

sudo lvm

Then inside LVM, run: pvdisplay

This shows all of the physical volumes. In my case:

 --- Physical volume --- 
  PV Name               /dev/sda5 
  VG Name               graylog-vg 
  PV Size               19.29 GiB / not usable 2.00 MiB 
  Allocatable           yes (but full) 
  PE Size               4.00 MiB 
  Total PE              4938 
  Free PE               0 
  Allocated PE          4938 
  PV UUID               ifegZp-w4fj-zQwe-8DQW-LWaB-CxOo-mL3qLG

Next, resize this volume by running:

pvresize /dev/sda5

This extends the physical volume to fill the rest of the space freed up via parted

Next, run the following command to show the new size:

pvdisplay

Next, run this command to show the logical volumes:

lvdisplay

Then resize the main logical volume:

lvresize -l +100%FREE /dev/graylog-vg/root

This resizes the selected volume to take up the rest of the free space

You can confirm the new size by running

lvdisplay

4. resize2fs

The problem now is that if you run "df -h" you still only see the originally-remaining free space. To fix that you have to run:

sudo resize2fs /dev/mapper/graylog--vg-root

angular.copy() error: "destination.push is not a function"

noreply@blogger.com (Anonymous) — Fri, 02 Sep 2016 13:35:00 +0000

Recentlly I got the following error:

TypeError: destination.push is not a function

Turns out I was trying to use angular.copy(source, target) where the target was an object and the source was an array.

When using angular.copy(source, dest), both types must be the same "type", either Object, or Array

MiniProfiler for AJAX calls with ServiceStack.Net

noreply@blogger.com (Anonymous) — Tue, 17 Apr 2012 16:40:00 +0000

I was surprised not to find this documented elsewhere on the Web.
ServiceStack.Net comes with a (slightly-modified) version of the MiniProfiler formerly-known-as "MVC MiniProfiler" now just referred to as "MiniProfiler" (http://miniprofiler.com) -- and it works great on their "HTML" service pages...but I wanted to get it to show on my MVC pages AND I also wanted it to update as I made JSON-formatted ajax calls to my web services. So, here's what I did:

First, I'll here's my "_Layout.cshtml" file:

You'll notice that I do RenderIncludes() before I include jquery. I had some problems doing it in the other order, all my AJAX calls were erroring.
RenderIncludes() produces an HtmlEncoded string, so you end up with a bunch of < and stuff in your code, I'm wrapping it with @Html.Raw so that we get the actual raw text on the page.

That takes care of rendering the MiniProfiler for your MVC controller logic, but now we need to handle the ServiceStack.Net AJAX requests. Here's the javascript I used:

Basically, I'm grabbing the special Response header that ServiceStack adds called "X-MiniProfiler-Ids" that's a JSON-formatted array of ID numbers that correspond to MiniProfiler line-items -- then I'm telling the MiniProfiler to go get the data for those Ids.
That's it. After that, it "just works"

Expression Design Slice Size Problems

noreply@blogger.com (Anonymous) — Fri, 08 Jul 2011 21:41:00 +0000

Expression Design will sometimes...very annoyingly refuse to export slices or even whole images at the dimensions you specify.

To summarize some other pretty long blog threads here and here

The interesting part is...I can replicate this problem with a line (even if the lines boundaries are *exactly* at pixel boundaries), but if I have a rectangle that's positioned at exact pixel boundaries, the problem goes away.

The fix is:

Turn of anti-aliasing

OR
If you can, use rectangles instead of lines

OR
Move vector shapes away from the edges of your image/slice

If you have lines right at the edge of your image and you have anti-aliasing turned on -- Expression Design decides that anti-aliasing is more important than your dimensions....surely you don't want to waste all that anti-aliasing data outside the edges :-) *sigh*

Weird Error Running ASP MVC 3 Site in Debug Mode

noreply@blogger.com (Anonymous) — Mon, 27 Jun 2011 23:41:00 +0000

Saw this error today:

It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.

Actually, the problem was I had edited the wrong web.config file :-)

In ASP.Net MVC, there's a web.config under the main root, and a web.config under the Views folder.

So, my tip of the day is, make sure you're editing the one you're supposed to be.

Darned SQL Agent Service

noreply@blogger.com (Anonymous) — Thu, 14 Oct 2010 00:09:00 +0000

This took me a little while to solve.

My SQL agent service would start and then immediately stop unexpectedly -- this is after running a repair of my SQL installation.

I took the advice given here: http://support.microsoft.com/kb/288577 and tried to execute SQLAGENT.EXE from the command prompt, and started down the path of troubleshooting the error message.

It wasn't until (much) later that I thought to try using runas to run the command as the user that the Agent service is configured to use.

Then, when I ran the command SQLAGENT.EXE -c -v, I got this helpful message:

2010-10-13 20:03:17 - ! [246] Startup error: Unable to read SQLServerAgent registry settings (from Software\Microsoft\Microsoft SQL Server\MSSQL10_50.TFS\SQLServerAgent)

After changing the permissions there, everything is working great.

Convention over Documentation

noreply@blogger.com (Anonymous) — Mon, 02 Nov 2009 20:23:00 +0000

Convention over Configuration seems to be an increasingly popular approach to software development, especially in a world of increasing development frameworks. I think the general principle holds a lot of promise for the world of IT as well.

What is Convention over Configuration?

I think the best place to start is to summarize the idea of Convention over Configuration -- and I think the best way to explain it is by an over-simplified example:

Imagine you have a framework that automatically took objects you've created in your code and saved them to database. A traditional approach would be to have some kind of configuration file that contains maps which classes go into which database table. Something like:
<class table="&biz_users"& name="&BusinessUser">

Using the principle of Convention over Configuration, the designer of the framework might simplify this and simply specify that all classes will be saved into database tables with the same name as the classes. While it may take a little bit of re-work to make sure class names will all make valid database table names, you are accomplishing several things:

You're removing a layer of complexity without significantly affecting your flexibility. You can still have tables named whatever you want, your code just has to match.
You're eliminating a whole series of bugs that could arise from type-o's or other errors in your configuration file.
You're making troubleshooting a lot easier, because you can look at the database and know exactly what class each table is representing without having to go back through an additional configuration file.

In short, you're saving yourself a lot of work and potential headaches.

How does this apply to IT?

I think the ideas behind this software development principle could more adequately applied to the IT field as "Convention over Documentation".

For IT shops managing multiple clients, often each client has their own set of documentation for how users are setup, how drives are mapped, how printers are installed, etc.

The principle of "Convention over Documentation" would say to come up with a standard set of "conventions" that your IT shop uses, then reconfigure clients to match these conventions and document any exceptions.

An Example

I think it's easiest to explain this with an example contrasting "Convention over Documentation" with a more traditional "Documentation-only" approach:

You may have some clients that have network printers directly installed on their PCs, other clients may have printers shared off the server and manually setup for each user, and others may have different kinds of scripts mapping network printers.

If you leave clients all configured differently, any support requests for network printer installations will involve:

Support technician looking up printer install documentation on this client
Support technician going through documented install process for this client (or more often, support technician going through whatever install process they are most comfortable with)
Support technician updating documentation on where printers are installed

And that's not even considering what to do if this is a request for installing a new printer, or the support technician needs to troubleshoot a problem with printing. If you have real-world IT experience, you've probably seen what kind of mess this process often produces.

Using the principle of "Convention over Documentation", the IT shop would have a standard procedure for installing network printers (hopefully one that enables centralized management). The process for setting up a printer for a new user would be more like this:

Support technician connects in to client's print serve and identifies the printer needed.
Support technician modifies user's Active Directory account so that group membership will trigger scripts to install this printer for the end user.

Hopefully, this will cover most cases, but like anything with IT, there will inevitably some client that needs printers installed differently from your established standard. I would argue that having a standard convention makes identifying exceptions more straight-forward:

While going through the installation process, if the printer isn't installed on the print server, or the appropriate Active Directory groups aren't created, this will trigger the support technician to go look for a documented exception to the standard configuration.

Arguments *for* "Convention over Documentation"

Reduces the amount of documentation, and therefore decreases the potential for inaccurate, out-of-date, or incomplete documentation.
Increases the speed at which support incidents can be addressed by: (1) reducing the amount of time the support technician spends reading documentation and (2) increasing the familiarity of the support technician with the client's configuration.
Reduces configuration mistakes since each configuration is basically the same.

Arguments *against* "Convention over Documentation"

The approach requires reconfiguring client's networks, which takes time
There will inevitably be some good reasons some clients may have for their network being inconsistent with an IT shop's established standards.

Personally, I think that, in most cases, the amount of time you save in the future and the other effeciencies gained by consistent configuration more than makes up for objection #1.

As far as #2, while you will inevitably have some exceptions, I think some simple guidelines will help with handling them effectively:

Make absolutely sure that an exception is required.
Make sure your standard process helps the support technician identify exceptions.
Keep all exceptions documented and keep the documentation easily accessible.

Overlooked Users

noreply@blogger.com (Anonymous) — Sat, 26 Sep 2009 04:05:00 +0000

When I'm trying to evaluate/install/manage software I sometimes feel like the software companies really don't care about my pain. They apparently think nothing of publishing pages of pre-installation notes followed by an installation with a myriad of painstaking steps that must be followed precisely or else you end up with an irrcoverable mess.

Now, sometimes they can get away with it when their products are popular enough that end users demand them -- like the Blackberry server.

But, companies that make less visible software should be careful. For example, Symantec's Corporate Antivirus product has a few notorious issues (failed uninstall cleanup, Outlook plugin issues) that aren't deal-killers in themselves. But, when an IT department looks to compare antivirus products, the idea of not having to deal with these problems can sound pretty appealing.

So, if you write software, keep in mind that end users aren't the only ones that have to use it. If you are causing the admins pain, you're opening the door for your competitors.

Usability and the Cloud

noreply@blogger.com (Anonymous) — Tue, 22 Sep 2009 00:54:00 +0000

I would argue that one of the benefits of the move towards cloud computing is improved usability. As more data is stored in the cloud, people need to manage it less, and fewer tasks mean more usable solutions.

Perhaps it's easier to illustrate with a "for instance":

Say you've got some newer computer users all using POP email into Outlook. Now they get new computers. Throw in multiple email accounts, some people sharing email addresses, and you've got yourself a real set of issues for most people.

Now, if you these same people had been using Gmail, hosted Exchange, or something like that, this process would have been a painless, 1-2-3 experience.

I'm not pretending that this ease of use doesn't come with some tradeoffs like ownership of data, service availability, and dependency on 3rd party systems.

But if you think about it, are most computer users more likely to have a system failure with inadequate backups or have a cloud provider go out of business? Delving into these issues is a topic for another time, but I hope you get my points.

For more advanced users, this may be an issue, but for a lot of people, removing system tasks from their scope of responsibility is a welcome change -- one that's worth the other risks that come with cloud services.

About this Blog

noreply@blogger.com (Anonymous) — Tue, 22 Sep 2009 00:31:00 +0000

I've been working with computers as long as I can remember. As a kid I remember using Wordstar on my dad's IBM 8088.

I remember the piece of paper that went over the function keys to help remind you that if you needed to underline something you would need to press CTRL+SHIFT+ALT+F7 or something like that.

Looking back, it's crazy to think that we used to think of that as an usable solution, but that's where technology was at the time -- that's all we had.

Doing anything with a computer involved having some significant knowledge, or knowing someone who knew how to do it.

Usually the "nerd" would begin their explanation with the phrase "all you have to do is...", and then would follow a series of technical steps that they thought were very simple, but that any non-expert would have very little chance of figuring out on their own.

Over the years, as technology has improved, the "nerds" are still around to give out these explanations, but as improvements in usability have moved forward, complicated steps to solving problems have become increasingly socially unacceptable.

Over time, I've come to believe that the reasons for a lot of usability problems aren't that it would take a lot of work to do things differently. Mostly, it's just that IT people (myself included) are like most people in that we forget that other people think differently than us. We are so used to designing solutions focused on how the computers work, we forget that the more important thing is to design thinking about how people work.

This blog is really just recording my journey trying to make the solutions I help design more usable, and therefore more effective.

I'll have my opinions, and I hope you as readers will share yours as well. Hopefully we can all learn how to create better solutions.