The Thoughts of Matt Palmer
I'm not into coffee, but this looks like it might be worth getting a taste for it...
posted at: 20:42 | category: /knowledge/recipes | permalink
Firebug looks interesting. From the homepage:
FireBug is a new tool for Firefox that aids with debugging Javascript, DHTML, and Ajax. It is like a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter.
posted at: 20:20 | category: /knowledge/software/firefox | permalink
So, you have two people who want to share a common terminal, but they don't want to (or can't) bang on the same keyboard and peer at the same screen.
Multiuser screen to the rescue!
You have two users, userH and userG, and one relevant machine, hostH. Both users have a terminal window on hostH (because both users have SSHed in, or one is on the local console, or whatever).
Requirements: ensure that the terminal window is the same size in both cases, and that the screen binary on hostH is SUID root.
UserH (the 'host' user) runs the following:
screen -S <some name>
UserH will then have a running screen session named "<some name>", and must then enable multiuser and allow the other user to connect by typing the following in their screen session:
CTRL-A :multiuser on CTRL-A :addacl userG
Now userG can run the following in their terminal:
screen -r userH/
And now both users are in a common screen session. Both of the users' keyboards will enter characters, so have some sort of out-of-band mechanism for collision avoidance. Either user typing 'exit' will quit the screen session. Remember that the session is running with the permissions of userH (who started the screen session), so don't do this with people you don't trust to peek at your pr0n stash.
posted at: 11:35 | category: /knowledge/software/screen | permalink
Since I'm not a subversion user particularly (and some of my Trac uses thus far aren't for code anyway), I want to disable the Browser tab in my Trac UI.
Simply add the following to your trac.ini file:
[components] trac.versioncontrol.* = disable
And then restart tracd (if you're using it).
Ref: The TracIni page in the Trac wiki, the [components] section. Specific LHS for the line comes from the "About Trac" Plugins subpage.
posted at: 20:30 | category: /knowledge/software/trac | permalink
On many cfengine-managed systems, you need to be able to create users for local purposes. Jamie Wilkinson, CFEngine guru extraordinaire, does it like this:
For system users:
groups:
user_X_exists = ( ReturnsZero(/bin/sh -c "/usr/bin/id -u X >& /dev/null")
)
shellcommands:
!user_X_exists.redhat::
"/usr/sbin/useradd -r -c X -s /sbin/nologin -d / -M -g nobody X
!user_X_exists.debian::
"/usr/sbin/adduser --system --gecos X --shell /bin/false --home /
--no-create-home --disabled-login --disabled-password --group nobody X"
I do it with macros, so I don't have to type all that crap for every system
user I need, and so things like home directory and default group can be
changed easily.
In a perfect world, this idiom would turn into a users: section, but alas
I've not yet had the time to write a patch.
For humans, I use LDAP, and cfengine just takes care of configuring the auth
system.
Michael Chesterton, on the other hand, prefers the modular approach:
module:users
#!/bin/sh
/usr/bin/getent passwd |\
/usr/bin/awk -F: '{print "+user_" $1 "_exists"}' |\
sed 's/-/_/g'
control:
AddInstallable = ( user_user1_exists user_user2_exists )
actionsequence = ( module:users shellcommands )
shellcommands:
!user_user1_exists.redhat::
"/usr/sbin/useradd -r -c X -s /sbin/nologin -d / -M -g nobody X
...
It seems to work without addinstallable, but the docs say to use it, so
I do, otherwise there is a little less typing.
posted at: 13:45 | category: /knowledge/software/cfengine | permalink
Date: Mon, 04 Jul 2005 13:27:31 +0530 From: NagappanTo: debian-qa@lists.debian.org Subject: Linux GUI Automation testing tool Hi, GNU/Linux Desktop Testing Project (GNU/LDTP) is aimed at producing high quality test automation framework and cutting-edge tools that can be used to test GNU/Linux Desktop and improve it. It uses the "Accessibility" libraries to poke through the application's user interface. The framework has tools to generate "AppMap" by reading through the user interface components of an application. The framework also has tools to record test-cases based on user-selection on the application. GNU/LDTP core framework uses "AppMap" and the recorded "test-cases" to test an application and gives the status of each test-case as output. As of now, GNU/LDTP can test any GNOME application which are accessibility enabled, Mozilla, OpenOffice.org, any Java application (should have a UI based on swing) and KDE 4.0 applications based on QT 4.0 (based on the press releases by KDE). We encourage you to join the project and help us to create robust, reliable and stable test tool/framework for Linux Desktops. http://gnomebangalore.org/ldtp/index.php/Main_Page
posted at: 10:56 | category: /knowledge/development | permalink
Presumably only XP machines...
http://www.windowsdevcenter.com/pub/a/windows/2004/05/04/serverhacks_remote.html
posted at: 11:10 | category: /knowledge/software/windows | permalink
(Distilled from http://www.sugarcrm.com/home/Sugar_Suite_Documentation/189/)
Offers the ability to create or update scheduled activities, or to search for existing activities. By managing Activities within the context of an Account, Contact, Lead, Opportunity, or Case, the true value of Sugar Suite comes to light. Sugar Suite allows you to manage the myriad of calls, meetings, notes, emails and tasks that you need to track in order to get your job done.
Contacts are the people with whom your organization does business. As with accounts, Sugar Suite allows you to track a variety of contact information such as title, email address, and other data. Contacts are usually linked to an Account, although this is not required.
Accounts are the companies with which your organization does business. Sugar Suite allows you to track a variety of information about an account including website, main address, number of employees and other data. Business subsidiaries can be linked to parent businesses in order to show relationships between accounts.
Leads are the people or companies with whom your organization might do business in the future. Designed to track that first point of interaction with a potential customer, leads are usually the hand off between the marketing department and the sales department. Not to be confused with a contact or account, leads can often contain incomplete or inaccurate information whereas contacts and accounts stored in Sugar Suite are core to many business processes that require accurate data. Leads are typically fed into the Sugar Suite system automatically from your website, trade show lists or other methods. However, you can also directly enter leads into Sugar Suite manually.
Opportunities track the process of selling a good or service to a potential customer. Once a selling process has commenced with a lead, a lead should be converted into a contact and possibly also an account. Opportunities help you manage your selling process by tracking attributes such as sales stages, probability of close, deal amount and other information.
Cases are the handoff between the sales department and the customer support department. Cases help customer support representatives manage support problems or inquiries to completion by tracking information for each case such as its status and priority, the user assigned, as well as a full trail of all related open and completed activities.
posted at: 11:10 | category: /knowledge/software/sugarcrm | permalink
It's really handy to be able to automatically generate tickets in RT when Nagios detects a problem. Complicating things slightly is the fact that Nagios has a bit of issue management built-in (notifications and acknowledgements) but not nearly enough to make it an RT replacement.
So, instead, we get this. It's a patch to Nagios to make it work better with RT. Probably not perfect workflow for everyone, though.
http://lists.bestpractical.com/pipermail/rt-users/2005-June/031775.html
posted at: 11:10 | category: /knowledge/software/nagios | permalink
It's really handy to be able to automatically generate tickets in RT when Nagios detects a problem. Complicating things slightly is the fact that Nagios has a bit of issue management built-in (notifications and acknowledgements) but not nearly enough to make it an RT replacement.
So, instead, we get this. It's a patch to Nagios to make it work better with RT. Probably not perfect workflow for everyone, though.
http://lists.bestpractical.com/pipermail/rt-users/2005-June/031775.html
posted at: 11:10 | category: /knowledge/software/rt | permalink