Friday, September 2, 2016

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

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

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"

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

Tuesday, April 17, 2012

MiniProfiler for AJAX calls with ServiceStack.Net

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:
  1. 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.
  2. 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"

Friday, July 8, 2011

Expression Design Slice Size Problems

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*

Monday, June 27, 2011

Weird Error Running ASP MVC 3 Site in Debug Mode

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.

Wednesday, October 13, 2010

Darned SQL Agent Service

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.

Monday, November 2, 2009

Convention over Documentation

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:


  1. 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.
  2. You're eliminating a whole series of bugs that could arise from type-o's or other errors in your configuration file.
  3. 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:

  1. Support technician looking up printer install documentation on this client
  2. 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)
  3. 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:

  1. Support technician connects in to client's print serve and identifies the printer needed.
  2. 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"

  1. Reduces the amount of documentation, and therefore decreases the potential for inaccurate, out-of-date, or incomplete documentation.
  2. 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.
  3. Reduces configuration mistakes since each configuration is basically the same.

Arguments *against* "Convention over Documentation"

  1. The approach requires reconfiguring client's networks, which takes time
  2. 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:

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