Browsed by
Tag: dslib

Diff Script for Applying DS Updates

Diff Script for Applying DS Updates

Here’s a command I wrote for DS lib, it goes in as /secure/cmds/admins/diffit.c and responds to the “diffit” and “help diffit” commands.

Steps to use:

  1. When an upgrade is available, do a `liveupgrade all`
  2. Once it has finished downloading, do a `diffit`. You will be prompted for each file that is being upgraded to [K]eep the current version, or [R]eplace it with the new version.
  3. Once finished, see /log/diff.log for errors, and /log/diffkeep.log for files you chose to [K]eep (You will need to upgrade these files manually).

Future features:

  • “More” for long diffs
SQL Daemon for DS

SQL Daemon for DS

With much anticipation, here is my SQL code: it allows both blocking and non-blocking SQL sockets to be used simultaneously. I’ve tried to be very verbose in my commenting, and I will include some examples later on, too.

This stuff works to the best of my knowledge. If not, leave me a comment and I’ll try to look at it.

Terminology:

  1. “Non-blocking SQL sockets” are sockets that execute a callback function once the SQL data is retrieved. Ideally, this is how you will access all SQL data. (Technically: This type of socket uses extern_cmds to pipe data to and from the ‘mysql’ command through the use of callbacks)
  2. “Blocking SQL sockets”, however, are sockets that take 100% of the driver’s attention until the SQL data is received. Nothing else is executed while it is in use. The ONLY reason you would use this type of socket is when you NEED a
    response from the SQL server before continuing to the next line of code. (Technically: This type of socket uses efuns compiled into the driver to communicate with the SQL server directly)

Planned features:

  1. Allow MSSQL, Oracle, and other databases
  2. Transaction support (Partially implemented so far)

The code contains three distinct sections:

  1. Shared code
  2. Exclusively “Non-blocking” code
  3. Exclusively “Blocking” code

Steps you will need to take to make this usable:

  1. Compile a driver with SQL support
  2. Make sure you have a usable SQL server
  3. Create a database for MUD-related stuff, default ‘mud
  4. Create a user for general-purpose access with only the required permissions (ie, SELECT, INSERT, UPDATE on non-sensitive tables only) and restrict the user to the mud database.
  5. (Optional, strongly recommended): Create a user for mud-admin access with only the required permissions (ie, SELECT, INSERT, UPDATE, DELETE) and restrict the user to the mud database.
  6. Place db.h in /secure/include/ and edit it to suit your installation
  7. Place sql.c in /secure/daemon/
  8. Edit /secure/daemon/master.c to allow the SQL daemon to access a socket (See attachment)
  9. Add “external_cmd_1: /usr/bin/mysql” (without the quotes) to /secure/cfg/mudos.cfg
  10. Create tables to support data for your mud (See attached “mud.sql“)
  11. Add SQL support to files that you want to be able to access the database (See attached examples)