Slashdot Mirror

It's open-source, but you can contract with them to do support and setup. The asset management plugin is easy to add and works great.

Incredibly customizable as well. They also have an incident response module that may be worthwhile to look at if you're managing multiple datacenters.

It's open-source, but you can contract with them to do support and setup. The asset management plugin is easy to add and works great.

Incredibly customizable as well. They also have an incident response module that may be worthwhile to look at if you're managing multiple datacenters.

I highly recommend using RT for tickets, and installing a plugin called Asset Tracker. You can have multiple types of assets with different fields for each asset, link assets in tickets, use REST or their command line tool for automated queries/updates, and much more. It is all open source, modular, and very easy to modify.

Request Tracker by Best Practical is quite powerful, although it can be a real pain in the butt to get installed due to Perl.

https://www.bestpractical.com/...

There are already a lot of suggestions for which particular package to use, so I'll contribute my thoughts.

I've used RT. It worked.

The main feature that helped me move my (financial services) office from word-of-mouth to proper tracking is that RT supported submitting issues by email. We already used internal email extensively for other workflows, so it was easy for me to convince people to send an email to <project>@tracking.<domain>, and they'd get an emailed response showing the ticket number and a link where they could follow the progress.

RT let me run different projects (which in my case usually meant only 1-3 people) separately, and each project had nice charts showing how many open issues they had to work on. Managers loved that, because they could see who was overloaded and by how much. Each user was also able to create their own dashboard to display when they logged in, so they could get a to-do list first thing in the morning.

For each project, I could modify what information was needed when a ticket was created. Almost the entire ticket form was customizable, so that was adapted to the project needs. For our financial advisors, they had simple forms with a customer name and a description field. Traders had buy and sell forms with security symbols, amounts, account numbers, et cetera.

I haven't been in a position to manage very many trackers, so maybe these features are standard-issue. Maybe something else will work for you, but like it said, RT worked for my needs.

First, read the PSNA if you haven't already, it features good ideas on documentation and especially process and how to deal with "layer 8" (management, users, whatever is the "real world" for you).

Next step is the wiki. You seem to already have that, good. People here have suggested SemanticWiki, but I'll point you towards Ikiwiki as it has the advantage of (a) being git based so completely decentralised (have a copy of your files on your laptop during a downtime!) and (b) written in perl so you can probably extend it.

Make sure people know where your wiki is and *use* it, so it doesn't become this rotten piece of outdated documentation out there. You have only started to understand how this is going to be a pain: documenting is hard long-term work. there's a (bad) reason why people don't do it effectively: it takes time and dedication.

Next you can consider using dedicated tools for certain things like inventory or issue tracking. We have used Request Tracker with good success. It's a very solid product that does a lot, also in Perl, coincidentally enough. It also has the Asset Tracker plugin to follow inventory, but i haven't personnally used that, although I had good feedback from peers that used it successfully in an heterogeneous environment. An alternative is OCS inventory, which I haven't used either.

So, just bite the bullet: you're going in the right direction. Just consider the right tool for the right job is your next step, i guess.

Asset Tracker works nice for us and is integrated inside Request Tracker. The web site only has the download item and the software is a little old but it runs surprisingly well.

A bit of personal commentary on him using it here (Jan 13 2009)

Request Tracker is actively developed and very robust http://www.bestpractical.com/rt/

A combination of Bugzilla and Wiki. Wiki keeps track of backlog. Bugzilla keeps track of tasks.

If you're going down this road, then just install and configure Request Tracker. It's got great workflow management, uses email (which works for all but network-related tasks) as the primary interface and has some great reporting tools, so at the end of every month you can hand your boss a shiny little report showing just how productive you are.

For bonus points, it also stores the history of every request, so if you need to, you can also demonstrate to your boss what a prick Henderson in HR is, and that you cut off his Internet access because he didn't seem to be able to stay away from Furry sites during working hours.

Okay, seriously: RT is well-designed, well-documented and well-supported. It's got a lot of solid add-ons (which might or might not have significance for a 1 man IT dept.), and though it takes a little effort to grasp, it's remarkably rewarding in terms of simplifying your day.

you really did not look well into it: http://bestpractical.com/rtfm/ [bestpractical.com] ; rtfm is really simple and useful, it works great.

I have barely looked at all - I decided a while ago that I'd rather move off RT entirely and extend our homebrew solution. It's easier for us and we'll get better customisation. I'll check that link out anyway though as it will prolly be helpful for the interim, thanks.

Were you using (old) pc hardware for the RT server? What OS did you install RT on? There has been quite a big problem with the perl version that redhat installed in their OS, so maybe you were bitten by it.

We were using an HP DL380 I think - dual processor xeon, 2gb RAM - it was pretty beefy. We upgraded it to 4gb RAM and got little improvement. But we WERE running Red Hat - so maybe we ran afoul of the perl problem you mentioned.

RT is fast, simple and like they say in their website:

Yep, and I do like that aspect of it. The simplicity and flexibility of it is nice. i just find the resource requirements generally seem to be massively high - a quad core xeon with 4gb of RAM to me seems like MASSIVE overkill for what is a relatively simple web application. That's part of the reason I think I unconsciously am pissed off with it - we had SO many problems with it performance wise that just didn't make sense (so it must've just been some stupid distro-specific bug that was causing it - I was away on holidays when it was resolved and don't know how they did it).

I just installed RT a couple weeks ago and I am really liking it. From others I have talked to it scales well. I am a one man IT shop and it allows for web interface and email (I have been using strictly email for the user's side). It even has an RTFM (RT FAQ Manager) component. ;)

http://www.bestpractical.com/rt/

you really did not look well into it: http://bestpractical.com/rtfm/ ; rtfm is really simple and useful, it works great.

As to your complaints about RT's performance: I am sorry, I cannot recognize any of it. Were you using (old) pc hardware for the RT server? What OS did you install RT on? There has been quite a big problem with the perl version that redhat installed in their OS, so maybe you were bitten by it.

I have run RT with a stock debian etch install and following the fine instructions that came with the distribution getting it working was a mere 20 minutes (ok, ok, I am a linux sysadmin, so I actually do read the docs, so maybe I am cheating). Our production RT was a proliant 360 dl g4 with 4GB ram (quad core xeon, nothing really fancy and it is now at least 3 years old, I am too lazy to look it up now). This is our intranet/internet webserver, being constantly pounded by quite a few webapps by 1500 users. I have not seen any performance issues at all.

Just because it is linux, it doesn't mean that it can make miracles. A database server remains a database server, and you need the hardware for it: fast disks are a must. if you have a virtual environment with fast disks i am pretty sure it will also run without problems.

Since there is no official asset support module, our company moved to topdesk and i can positively tell you that I miss RT a lot while doing tech support to our users. The search function is brain dead, the workflow is brain dead and the web interface is brain dead. It wants to be a desktop app with tabs and that sort of stuff and that really slows you down. RT is fast, simple and like they say in their website:

Help requests without my RT remind me of TV without using TiVo to skip commercials: I can only stand it for a short while

Unfortunately, the asset tracker extension is not part of RT, hopefully this changes in the future (http://code.google.com/p/asset-tracker-4rt/)

Where I work (3000+ employees) we make use of Request Tracker.

It's an OSS ticket tracking system written in OO Perl, has a SQL backend, plugs into kerberos and scales pretty well.

http://bestpractical.com/rt/

There is an official RT extension for doing "standard responses." It's called RTFM. (RT Faq Manager) http://bestpractical.com/rtfm/. Our customer support loves it.

I second the recommendation of Request Tracker, or RT: http://bestpractical.com/rt/

However I have not used many other systems, although we tried to do this with GForge (GForge has come a long way since we were using it).

Also, I have found the people on #rt on irc.perl.org to be polite and helpful, even when my questions were stupid. Thanks guys !

Unfortunately, my company uses the godawful Siebel.....

http://bestpractical.com/rt/

What about RT? http://bestpractical.com/rt/

I'm a big fan of rt3 ( http://bestpractical.com/rt ).

Pros:
- Free and open source
- Web, email, and command line interface
- Flexible (I've used for bug tracking, support departments, task and project management, documentation, mailing lists, and more)
- Scalable (I've seen it go beyond 100,000 tickets on an average server with no performance hit)
- Excellent community (mailing lists, wiki, book, contrib section on the site)

Cons:
- Written in Perl, so its a bit tricky to configure and customize

Give it a try.

A few years ago, I worked for a network operations center at a university, and we managed the internet access of over one hundred thousand users (mostly the university interconnects and the internet gateways, not everything down to the dorm room or anything like that). We were toying with the idea of using a ticketing system to handle issues that cropped up, and I was asked to evaluate some open source software packages.

Eventually, I found Request Tracker, slapped together a demo server, and showed it to the "Director of Technology." He stroked his beard. "It's okay," he said, frowning, "but the ticket you just created has the ID number of 1."

I shrugged. "Well... yeah," I said. "It's the first ticket."

He shook his head. "That's not going to work. We need to be able to start it much higher. Otherwise everyone is going to know that the software is new."

I stared at him. "We get phone calls from about two dozen network engineers," I said. "We're on a first name basis with all of them. I think the giveaway will be that they get a ticket number at all, not that it's low."

But he was adamant. I was annoyed enough by the whole conversation that I stopped working on it, and for all I know they're still not using a formal ticketing system. (Which is probably just as well, because even if they'd started a ticketing system at id # 0, four years later they'd probably be into the low three digits.)

I'll experiment with using DVCS on a project soon and will see if the shortcomings are less significant than I am making out.

I'll assume you've downloaded and installed SVN and SVK.

First step is mirroring:
user@host$ svk mirror svn://repository/url //mirror/project
Committed revision 209.

Sync the whole SVN repository locally:
user@host$ svk sync //mirror/project
Syncing svn://repository/url
Retrieving log information from 1 to 4
Committed revision 210 from revision 1.
Committed revision 211 from revision 2.
Committed revision 212 from revision 3.
Committed revision 213 from revision 4.


Has the mirror happened?
user@host$ svk mirror --list
Path Source //mirror/project svn://repository/url


Now, I find the naming of the 'mirror' strangely counter-intuitive. The mirror doesn't get modified by your changes until the server gets modified. It is truly a mirror, which is why I say it's 'strangely' counter intuitive.

The implication of this is that whether or not you make a local branch affects how you commit. To simplify the thinking, I'll ask a question. Take the option appropriate to the answer you give. The question is - when you commit changes, would you (a) like to commit directly back to the mirror, or (b) to commit to a local repository, and only later back to a mirror?

If you prefer to work in mode (a), you can do:

user@host$ svk co //mirror/project
Syncing //mirror/project(/mirror/project) in /home/user/code/project to 213.
A project/documents
A project/documents/StoryOverview.doc
A project/documents/StoryChapters.html


And edit the files... Type 'svk ci' to commit your changes. Your changes will affect the mirror immediately, and therefore the *server* at svn://repository/url immediately.

If you have a preference for (b), you should:

user@host$ svk copy //mirror/project //local/project
Waiting for editor...
Committed revision 216.

user@host$ svk co //local/project
Syncing //local/project(/local/project) in /home/user/code/project to 216.
A project/documents
A project/documents/StoryOverview.doc
A project/documents/StoryChapters.html


Now, when you type 'svk ci' commits are made only to the *local* repository. To push them back to the main repository (on the server) you need to type 'svk push'. To freshen your local copy with changes from the server, type 'svk pull'.

... at some of the Subversion conferences they have even talked about adding support for the offline access to a local copy of the repository.

meanwhile, if you're using SVN on Unix/Linux boxes, you might want to check out svk. All the advantages of a DVCS, but with the central repo being a (possibly pre-existing) standard svn server.

(I put the disclaimer about unix boxes in because the last time I had a colleague on a Mac running SVK, there were some minor issues around binary files and line ending munging... I don't know if they are resolved already or not...)

Is that supposed to be a pun :-)

I guess you mean this project. That does look interesting. Thanks!

use something like RT

What I've done in our repository is create a /users tree. Every person with commit access gets a directory here if they want one. People have free reign to do whatever they want within their user area. They can create as many private branches as they need without fear of fouling up the /branches tree.

Alternatively you can use svk.

I work at a help desk for that supports a 1/3 of the College of Engineering, and we use http://bestpractical.com/rt/

Its Perl based, might be overkill for your purposes, but its very good and free.

We've tried a variety of them, and RT is the favorite here [major university/supercomputer center's IT department]. [Likewise for some other centers].

I am surprised people still have to ask this question. RT is probably the most most mature Free Software for this purpose (having been around since 1998 or so). Several entities, big and small, use it - take a look at their "praise" page. I personally find that most small businesses I have had to email for support (Vandyke Software, for SecureCRT - an example) use RT.

Several suggestions you'll get here would be for bug tracking tools. Those are not what you want - you want a trouble ticketing system; and that is RT.

This question has come up before, and I usually answer the same way. RT: Request Tracker is a good place to start. It is a Perl+Apache+MySQL based open source solution. The first few times you install it can be tricky. Find a good and current how-to.

I have since moved away from RT and now use an in-house designed system. But I still give it two thumbs up.

Been using RT as a ticket tracker at a few places I've worked at. Works well.

I was at the talk and I have to say he lost a HUGE amount of respect from me (and other people in the room whose job has to do with source control).

The way git works as a decentralized solution with a chain of trust is simply not useable for really large, multiple projects with interdependencies. And it's even worse when you need to control access to certain portions of the code.

I see Git as a pyramid scheme with Linus sitting on top. I can't start imagining the job of the poor release engineer in a big corp who would need to merge the changes of sub-engineers and the chain of trust involved to reach the top ! What I see is that everyone would code and test on out of sync code, a bit like Vista's development was.

Git is a solution that is fine tuned to Linus specific needs, but it's ages away from a solution that's flexible for most of the industry's needs.

I'm a big fan of subversion, and while I'll admit it's far from perfect it's way better than cvs could ever be. It does the job well most of the time, and SVK is filling some of the holes.

svk is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.

http://bestpractical.com/rt

It was what my previous employer used. It has lots of features, and is quite easy to use and setup.

Or better yet, SVK.

I've always had good results with Request Tracker, which does a lot of this for you and is time-tested open-source:

http://www.bestpractical.com/rt/features.html

Two options.

1) If you are using analog phones, this likely will not apply to you

However, if you use VoIP based on something like Asterisk, you could force-open a trouble ticket when a call comes in to the support line. This way, they are forced to go in and close it, which should lead them to putting notes in it. You could further auto-assign the ticket to them if it went to their phone.

We currently do this when someone calls our on-call number- there's a big annoying ticket setting there awaiting resolution. Once this is working, set up some automated job to spit out a text listing of who has unclosed tickets, how long they've been open, etc. Have this list sent to all techs automatically.

We use RT for tickets, so creating new tickets in the appropriate queue can be done a few different ways. Sending an email to the account we have setup to create the tickets is the way

2) Incentives ($$)- bonuses and raises based on time/tickets/minutes logged. Nothing logged? No money for you.

--falz

The most pervasive one I've seen is RT.

is RT at http://www.bestpractical.com/rt/ and RTx::AssetTracker at http://atwiki.chaka.net/

RT is a very powerful open source ticketing system, and RTx::AssetTracker adds adequate asset tracking to it. You would probably have to do a bit of work to get it to work with barcodes (or just use a barcode scanner with the
cursor on the right page - most just send standard keyboard type input IIRC).

It's all open source, written in Perl, and really just works very well. And if it turns out to be inadequate, you'll learn enough from the experience to have a much better idea of what you actually need.

http://www.bestpractical.com/rt

Whatever features it's missing, I'm sure they'd be happy to add for you at way less than what the above recommendations cost.

request tracker from best practical will do lots of cool stuff, even authenticate users over LDAP. http://www.bestpractical.com/

Asset Tracker, a system which integrates wonderfully with Request Tracker is worth looking at, definitely. It has something of a learning and configuration curve, to be sure. Once you're over that, though, it works like a charm. Oh, and the price is right, too: Free.

1) E-mail is not a file transfer protocol.
2) Public folders (in the Microsoft Exchange sense) are not meant for use as a file server

Next you have to get management to purchase a couple things:

1) An on-demand e-mail archival solution. This product should integrate with your MUA (probably Outlook). The users should be able to locate and extract an archived email from the archival solution quickly and with minimal effort; otherwise the solution will not be utilized.
2) A better spam filter. I'd be willing to bet that a large part of your mail store is spam. There is no auditing requirement to archive non-business-related e-mail. Can the spam.
3) A web-based file-transfer/file-sharing solution. Since you're going to stop people from receiving large attachments via email (you are, aren't you?) you need to provide a method of transfer. One method is to use any of a hundred free or commercial trouble ticketing products like Request Tracker or even Bugzilla to create a secure way to transfer files between an external source and an internal employee by attaching files to an open and assigned ticket. There are numerous products out there that can satisfy this requirement, especially in these post-Sarbanes-Oxley/HIPAA/GLBA/etc times.

Next up is to clean up the PST nigthmare. I was recently involved as a consultant in the IT department of a company about your size. Dozens of their users had reached the 2GB PST limit numerous times. Their PSTs were rotated out and they simply started a new PST. The old PSTs were of course opened automatically within Outlook. These PSTs were stored on the company's main file server in the users' home directories. At some point we eventually realized that all incoming mail was delivered straight to PST instead of the users' mail spools in the information store. The day after this one of our Windows admins happened to notice that the text of the users' home directories were blue. That's right; they were compressed. Whoops! As a temporary solution for a failing mail server the previous admin staff decided to deliver mail straight to PSTs. This of course became the long-term practice. Soon they ran low on disk space. To solve this the temporarily enabled compression on the single large volume that this Windows server served to the LAN. This too became the long-term solution. Uncompressed I want to say that the data was around 800GB. Compressed it was 450GB or so. The admin staff didn't tell management what was going on and to the best of my knowledge management didn't ask or simply thought all was well. Our Windows admins are still trying to clean up this mess and these are the best Windows guys I've ever met.

Instigate policies that limit the amount of time received mail, sent items, deleted mail, drafts, etc are kept in the main inbox. A good archival solution should be able to mimick your policy in its config. Delete the deleted items daily. Dump the drafts every 2 weeks. Archive the sent items once a month. Archive the inbox every 3 months (quarterly, twice a year, whatever fits your needs).

Above all you have to get management's support and backing. Without that your pissing in the wind. Some squeaky-wheel middle management person with a Napolean-complex will put the brakes on the whole thing if you don't have upper-management's support. To get this support show them in dollars how much it would cost to restore the entire PST collection if you had a SAN failure (you do have a SAN, don't you?). Show them how much time you spend each week restoring mailboxes of enourmous size. Show management auditing requirements and how you don't meet them with your current setup. There's a lot you can do. Best of luck.

I recall using RT (http://www.bestpractical.com/rt/features.html, I think) a few years back, and finding it very easy to set up and use. Clients even used it, as it could be linked to emails... Very cool.

Request Tracker

We've decided to 'implement' Computer Associates ServiceDesk.
Do. Not. Use. This. Product.
Go to http://www.bestpractical.com, download RT3 and ask them about support if you need it.

http://www.bestpractical.com/rt/

It's what we use. It parses email to open tickets, generates replies, allows you to track an issue, handles attachments and it's open source.

HTH,

Queen B

Oops. No PHP, just perl. It's been awhile.

And the database choice is flexible.

http://wiki.bestpractical.com/index.cgi?ManualRequ irements

Another option (a little more modern) would be RT. Our security group is using it with success. They get at least a hundred new tickets every day and RT made it possible for them to deal with all of them in a timely manner.

Might be a little overkill.

But it's got the necessary features and much of the advanced stuff. I've used this at a job and it worked well. Hardest part was the setup (short-steep learning curve for the initial config).

Install went smooth enough.

MySQL, apache, PHP base. Maybe some other stuff needed too.

Cons:
    - Too many options to sometimes (overly complicated) maybe.
    - Without a nicer template, the default look isn't pretty. Maybe not so hot for customer facing.
        * There might be nicer skins. I didn't bother looking.

http://www.bestpractical.com/rt