GEMini Atari

home *** CD-ROM | disk | FTP | other *** search

/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / bbs / fn132bin / fdman / chapter.04 < prev next >

Wrap

Text File | 1991-09-03 | 38KB | 802 lines

Chapter 4: Aide and Co-Sysop Command Reference 62 4 Aide and Co-Sysop Command Reference If you are a normal person, the fact that you are also the Sysop won't confer the much-needed qualities of omnipresence and omniscience on you. The fact is you just can't do everything required by running your system, all the time. You may be able to get away without doing it all, but if you want help, the thing to do is grant Aide and/or Co-Sysop status to a select few users of your system. An Aide has powers greater than those of a normal user---he/she may delete messages, edit certain attributes of rooms, etc. A Co-Sysop has powers which are still greater---he/she may do everything an Aide can do, plus fully edit rooms, journal (copy) messages to files on disk, and many other things. Note that we make a distinction between ``a user with Co-Sysop status'' and ``the Sysop''. Both have the same Sysop privilege flag set in their user configuration, but the latter is a quick way of saying ``you, the guy/gal who runs the system''. We tend to assume that you will grant yourself all the powers in the book---but there's nothing that says you have to. 4.1 Aides In addition to having access to all the commands described in Chapter 3 [User Command Reference], page 24, any user with Aide privileges (or the Sysop or any Co-Sysop, of course, since they also have Aide privileges) will also have access to the additional commands described in the following sections. They will also be able to enter the special room called Aide>, where system messages from Fnordadel are logged, and where discussions can be held without concern that any non-Aide will ever get into the room. Many Aide commands causes changes of one form or another to your system. Most changes are accounted for by Fnordadel and are recorded under the Aide's name in the Aide> room for scrutiny by you and other Aides. If a person is found to be abusing the Aide privileges, you may then take such action as you see fit. 4.1.1 Granting Aide status For now, suffice it to say that you must explicitly grant Aide status to any user. The command to do this is documented in Section 5.2 [User Status Commands], page 80. Chapter 4: Aide and Co-Sysop Command Reference 63 4.1.2 The .A(ide) command Most of the additional functions available to users with Aide status are accessed via the .A(ide) extended command or its floor mode counterpart (coming up next section). Executing .A(ide) ? will show you a list like this: [C]hat with sysop [D]elete empty rooms [E]dit current room [K]ill current room [S]et time and date .A(ide) C(hat) This command is identical to the regular single-key [C]hat command, with one exception: it will override the Sysop- settable chat flag, and page the Sysop regardless. For more details on the chat flag, see [C]hat toggle in Section 5.1 [Sysop Special Functions], page 75. .A(ide) D(elete empty rooms) This command will cause Fnordadel to do explicitly what it normally does implicitly: search out and destroy all temporary rooms on the system that currently have no messages in them. It will delete the rooms' floor as well, if no rooms are left in it after the empty ones have been toasted. For more details on temporary vs. permanent rooms, see Section 2.2 [Rooms], page 15. Use of this command is logged in Aide>. Use of this command is *not* affected by the setting of the `ctdlcnfg.sys' parameter #aidekillroom, which determines whether .A(ide) K(ill room) and ;A(ide) K(ill floor) are executable by Aides and Co-Sysops, or just Co-Sysops. The Sysop can, naturally, blow away anything at any time. .A(ide) E(dit current room) This command brings up a new menu consisting of various room-editing options. Any Aide can use the commands in the following list, while users with Sysop or Co-Sysop status have these plus a few more (see Section 4.2.1 [Sysop room-editing commands], page 70). Use of this command is logged in Aide>. See Section 2.2 [Rooms], page 15, for a dissertation on many of the room features manipulated by these commands. [C]hange name [E]vict user [I]nvite user [K]ill room description [L]- edit room description [M]- toggle readonly status An[O]nymous room [P]ermanent [T]ype (Public/Hidden/Invite-only) [V]alues of room e[X]it Chapter 4: Aide and Co-Sysop Command Reference 64 [C]hange name This command does the obvious, and allows the alteration of a room's name. A room's name should, in general, reflect the purpose or topic of the room, which sometimes changes. But what the heck---it's your system, use whatever names you like. We give you permission. [E]vict user This command allows the eviction of a user from a private, invitation-only room. A user so evicted cannot return to the room even by knowing the full name, so you need not change the name of the room for security reasons. [I]nvite user This command, if you're with us so far, will be clear. It permits the invitation of users into private, invitation-only rooms. Knowing the room name isn't enough to gain access. Note that you as The Sysop (or anyone with Co-Sysop status using your system from the console), will always have access to any invitation-only room, whether invited or not. [K]ill room description This command wipes out the description file for the room being edited. The contents of this file, which are formatted like a message, are displayed for users via the [I]nfo command at the room prompt (see Section 3.1.1.3 [Other room prompt commands], page 29). [L]- edit room description This command creates (if it wasn't there) and allows the editing of the description file for the room being worked on. The description file can be viewed by users using the [I]nfo command at the room prompt (see Section 3.1.1.3 [Other room prompt commands], page 29). Since the file is formatted just like a message, we let you use the standard message editor to edit the file, with some restrictions on the commands available at the editor prompt. A `ctdlcnfg.sys' parameter called #infomax controls the maximum size of info files. The file will be called `roomnnnn.inf', where nnnn is the room's number in four digits. All `.inf' files are kept with the `roomnnnn.sys' files in the #roomdir directory defined in `ctdlcnfg.sys'. [M]- toggle readonly status The `M' key was chosen for this command for no good reason, but other better choices were already in use. Its function is to change the room into read-only status, or back to normal. A room that is read-only Chapter 4: Aide and Co-Sysop Command Reference 65 cannot have messages entered in it except by Aides, Co-Sysops and the Sysop. An[O]nymous room This command will toggle the room into or out of anonymous mode. When the room is anonymous, user names and date/time stamps will not appear in the headings of messages posted to the room. Changing an anonymous room back to normal won't bring the headings of previously-saved messages back; Fnordadel throws them away permanently for security. Basically all you will get in the heading of anonymous messages is a unique message number, which can be used by people wishing to refer to a specific message in a reply. [P]ermanent This command will toggle the room from temporary to permanent or vice versa. Rooms default to temporary, and you should leave them that way unless you particularly want certain rooms to become fixtures on your system. Temporary rooms are good because Fnordadel can automatically delete them when they are empty, if somebody tries to create a new room and there is no space for it, or if you run configur while the room is empty. [T]ype (Public/Hidden/Invite-only) This command allows you to change the room's basic type, choosing from among [P]ublic, [H]idden (normal private), and [I]nvitation-only (private requiring invitation). When rooms are first created, they may be made either public or hidden, but not invitation-only. The latter restriction is in place to prevent a proliferation of invitation-only rooms springing up should you grant room creation privileges to all users, in `ctdlcnfg.sys'. Making a room hidden will cause Fnordadel to ask you if you want to make all non-Aide users' accounts forget about the room (just as if they had used the [Z]) command). If you answer `no', anybody who had been using the room before will still have immediate access to it as a hidden room. If you answer `yes', Fnordadel will make all users forget about the room. They can still get back into it by using .G(oto), if they remember the full name. If you change the name, normal users can't get back. Users with Aide or Co-Sysop status can still get back in, however, since the room will appear in their .Z(forgotten rooms) list. Making a room invitation-only is similar. You will be asked if you wish to make all users forget about Chapter 4: Aide and Co-Sysop Command Reference 66 the room. Answering `no' leaves everybody with access who had it before. Answering `yes', however, turfs *all* users, including Aides and Co-Sysops, out of the room. Co-Sysops can get back in without being invited, but all other users (including Aides) will need an invite to regain access. Note that the Sysop can get into any room at any time, regardless of its type and his or her explicit invitation to it, or lack thereof. If the room in question is a shared network room, there is yet another wrinkle to the process. Making users forget the room for both private types will force you to reshare the room will all network nodes that the room is linked to. This is an unfortunate side-effect, but an unavoidable one (for now), due to the way room-sharing and access to private rooms work. The two features may not look related, but they are internally. [V]alues of room This command simply displays the current settings of the room. If executed by the Sysop or a Co-Sysop, the usual information will be augmented by a list of the net nodes sharing the room, if any. e[X]it This command returns the system to the room prompt. Any changes made to the room will be logged in Aide> at this time. Given that there are some special rooms on your system (your lobby room, Mail>, and Aide>), there are some exceptions to the above commands. For instance, it would make no sense to make Aide> temporary, or Mail> anonymous. Thus Fnordadel enforces some restrictions when editing special rooms. Note that since the .A(ide) E(dit) command is one of the most frequently used Aide commands, Fnordadel has a short-cut single-key command, [A]ide. .A(ide) K(ill current room) This is a fairly extreme command, in that it is not possible to reverse its effects. Use the command when a room has outlived its usefulness, and you wish to destroy it, even if it has messages in it. (If the room is the last on its floor, the floor will disappear, too.) Once the command is executed, the contents of the room are gone for good. You can always recreate the room, but the messages from it are unrecoverable. Use of this command is logged in Aide>. A `ctdlcnfg.sys' parameter, #aidekillroom, can be used to disable this command for Aides; if set to `0', the parameter allows only the Sysop and Co-Sysops to execute this command. Chapter 4: Aide and Co-Sysop Command Reference 67 .A(ide) S(et time and date) This is an infrequently-used command, but one that can come in handy now and then. Using it, any user with Aide status can alter your system's date and time. ``Why is this function necessary?'', you might ask. Aside from the aesthetic appeal of having the correct date and time stamped on your system's messages, the main reason is networking. If you transmit networked messages with incorrect date/time stamps, things can get screwed up on the systems receiving the messages. For more details, see Section 8.4.3 [The loop-zapper], page 115. 4.1.3 The ;A(ide) command Just as an Aide can manipulate individual rooms, so it is with entire floors. The ;A(ide) command allows this. Executing ;A(ide) ? will produce: [C]reate a floor [E]vict users [I]nvite users [K]ill this floor [M]ove rooms to this floor [R]ename this floor ;A(ide) C(reate floor) There is always one floor by default when you first configure your system. This command allows for the creation of new ones. When executed, it will cause the system to ask for the new floor's name, followed by a list of existing rooms to be moved onto the floor. If no rooms are put on the floor, Fnordadel will throw it away immediately, so be ready with at least one room. Use of this command is logged in Aide>. Floors can be private in that if the user currently signed on does not have access to any room on the floor (which means they are all hidden or invitation-only), Fnordadel will not show any information about the floor to the user. ;A(ide) E(vict users) This command allows an Aide to evict any number of users from all hidden and invitation-only rooms on the current floor. The users' access to public rooms will not be altered. ;A(ide) I(nvite users) This command does the reverse of the above, and allows an Aide to invite any number of users to all the hidden and invitation-only rooms on the current floor. The sole exception is the Aide> room, which can not be entered by invitation, only by possession of Aide status. ;A(ide) K(ill this floor) This is a potentially deadly relative of the .A(ide) K(ill) command. If used by an Aide signed on from remote, it will simply move all rooms from the current floor to the base floor Chapter 4: Aide and Co-Sysop Command Reference 68 (the first one on the system, which contains your lobby room), and then destroy the current floor. When used by the Sysop or a Co-Sysop, however, it allows the option of performing a `.AK' command for each room on the floor, and then deleting the floor itself. Use with caution, and keep lots of backups. Use of this command is logged in Aide>. A `ctdlcnfg.sys' parameter, #aidekillroom, can be used to disable this command for Aides; if set to `1', only the Sysop and Co-Sysops may execute this command. ;A(ide) M(ove rooms) This command allows additional rooms to be moved onto an existing floor. You may need to do this from time to time as room topics change, or as users create rooms without putting them on the right floor. Use of this command is logged in Aide>. ;A(ide) R(ename this floor) This command allows a floor name to be changed. Simple! You guessed it, use of this command is logged in Aide>. 4.1.4 Aide message deletion and movement So far we've looked at commands for dealing with rooms and entire floors, but they are only half the story without some way to deal with individual messages as well. Thus any user with Aide privileges also has powerful message-related commands to play with. [D]elete message Any user can delete his or her own messages, subject to some restrictions (see Section 3.7 [Deleting Messages], page 60). There are times, however, when messages will need deleting, and the author will be either unable or unwilling to do it. Enter a fearless Aide or Co-Sysop, who has the power to delete any message posted in a public room, using the same methods available to regular users. To recap those methods, here they are: 1. While reading messages normally - Use normal message reading commands (e.g. [N]ew or [R]everse) to display the desired message on screen, and [P]ause the system somewhere in the body of the target message's text. - While the system is paused, hit `D' for [D]elete. - The system will resume displaying the message through to its end, then display a prompt like this: [C]opy [D]elete [M]ove [A]bort: Chapter 4: Aide and Co-Sysop Command Reference 69 - To delete the message, hit `D'. To abort the process, hit `A'. 2. While reading messages using `more' - Since the above method can be cumbersome, or downright difficult in the case of small messages that scroll by before you can pause the system, users may also select the [D]elete command from the .R(ead) M(ore) prompt. See Section 3.6 [More Mode], page 59. - The rest proceeds as above. In addition, any Aide can delete private Mail> messages either to or from himself or herself, at any time. An exception to Aide deletion powers are messages found in the Aide> room itself. Any message deleted by any user is never lost (except for Mail> and anonymous messages, which are instantly vaporised for security reasons). Rather, it is deleted from its original room and moved to the Aide> room. Thus, deleting a message in Aide> has no effect. [M]ove message In addition to simply deleting messages, an Aide can move them from one room to another. The [M]ove command is accessed from the same prompt as the [D]elete command above, as the observant among you will have already noted. The system will then ask for the destination room for the message. The default destination is the last room to which a message was moved, or the Aide> room if no moves have been done since the system was last started. Moved messages are added to the destination room, and deleted from the source room (unless it was Aide>, from which no messages may be deleted). Note that you currently cannot move messages into Mail>, for two reasons. First, the code to get this working would be really ugly, and second, we couldn't think of a good reason for doing it! If you need to send the text of a public message to somebody in Mail>, investigate the C(apture) modifier of the .R(ead) command. See Section 3.2.2 [Multi-key read commands], page 38. Also note that messages moved into shared rooms probably will not be sent out on the network. We want to fix this, but because networking is based on message ID numbers, and the [M]ove command copies a message whole, including its ID number, the network code can't operate correctly. If you need to net the message after moving it, again consider using the C(apture) modifier of .R(ead); see Section 3.2.2 [Multi-key read commands], page 38. Alternatively, if the message is a local message, and you have Co-Sysop status, you could move the message into a net room and then use the pr[O]mote command from the .R(ead) M(ore) prompt to Chapter 4: Aide and Co-Sysop Command Reference 70 turn the message into a net message. See Section 3.6 [More Mode], page 59, and Section 4.2.3 [Promoting local messages to net messages], page 73. [C]opy message Copying a message looks and acts like moving one, except that the copied message is not deleted from the source room. This command is rarely used, but it's here if you need it. The [C]opy command is available from the same prompt as [D]elete and [M]ove. All the restrictions/foibles that apply to [M]ove also apply to [C]opy. 4.1.5 .E(nter) R(oom) At the Sysop's discretion, the creation of new rooms on the system may be restricted to users with Aide (or Co-Sysop) status. (See the #roomok parameter in `ctdlcnfg.sys'.) This limits the average user's creativity on the system to posting messages about topics chosen by others. On the other hand, it gives the system more direction and control; in our experience, heavy user input in room creation can lead to a quick monopolization of the system by drivel rooms. Don't mind us, however; we admit to being jaded oldsters. 4.1.6 Aide doors Door commands can be set up so that only users with Aide status can run them. See Chapter 9 [Doors], page 126. 4.2 Sysop Commands and Perks A user with Sysop privileges is automatically given Aide privs as well, so all of the commands described in Section 4.1 [Aides], page 62, apply to the Sysop and Co-Sysops. There are, however, a few more things that the Sysop and Co-Sysops can do. They are detailed in this section. 4.2.1 Sysop room-editing commands The room edit menu is accessible using the command .A(ide) E(dit) (see Section 4.1.2 [The .A(ide) command], page 63). Certain of its commands, though, are usable only by the Sysop or a Co-Sysop, due to their powerful or sensitive nature. Only the Sysop or Co-Sysops are allowed to edit the Lobby> and Aide> rooms; some of the following commands may not be usable on them, however. [A]rchive room [D]irectory status [N]et readable [R]eadable [S]hared [U]nshare Chapter 4: Aide and Co-Sysop Command Reference 71 [W]ritable [Y]- toggle backbone status [Z]- autonetted room [A]rchive room This command allows you to specify that the contents of the room be archived into a text file for more permanent enjoyment, later publication, or blackmail purposes. The system will prompt you for the path name of a file to use. It may be located anywhere on your storage device(s), but we don't recommend putting the file on a RAMdisk, for obvious reasons. When you toggle archive mode on and have specified a file to use, Fnordadel will archive all of the existing messages to the file immediately. It will then archive new messages as they are entered, until your storage device runs out of space or your toggle archiving off again. Watch the file's size to be sure that it doesn't get too large. Fnordadel may not generate an error message if the storage device runs out of room, and you will lose all messages that it subsequently tries to archive to the file. Fnordadel makes use of a file called `ctdlarch.sys', which lives in your #sysdir, to hold the archiving filenames. It consists of lines of the form <room number><SPACE><full-filespec> It is an ASCII file, so it can in fact be edited by the Sysop without having to go through the .A(ide) E(dit) stuff if you want to change the archiving filename to something else. [D]irectory status This command allows you to attach a subdirectory somewhere on your storage device(s) to the current room, and turn the room into what is called a directory room. When prompted, enter any complete pathname. If it doesn't specify an existing directory, Fnordadel will give you the option to create it on the spot. The [D]irectory command also permits you to turn a directory room back into a normal room. If you do this, Fnordadel will keep track of what directory was in use. If you later want to switch the room back to a directory room again, you need not worry about forgetting which directory was used before. [N]et readable This allows you to toggle net readable status on or off for a directory room. If it is net readable, this means that any system with which you network can call up and request files out of the room during a networking session. [R]eadable This option is like [N]et readable, above, but it controls whether normal users are able to access the room for downloading purposes. If you toggle readable status off, users will not be Chapter 4: Aide and Co-Sysop Command Reference 72 able to see what files are in the room, or download them. This command does not affect the Sysop or Co-Sysops. [S]hared This command allows you to make a room networked, and share it with one or more other systems. The systems must be in your net-list. The command will also make a shared room unshared if you wish, but doing so does not currently unshare all the net nodes from the room before making the room normal. Thus you should use the next command to disable all nodes, and then use this command to make the room non-networked. See Section 8.4 [Roomsharing], page 112. [U]nshare This command allows you to turn networking off in the current room, for one or more nodes. Nodes that you do not specify in this command are unaffected. For the nodes to disable, enter their names one at a time when prompted. To finish, answer the prompt with just a `<CR>'. See Section 8.4 [Roomsharing], page 112, for more information. [W]ritable This command allows you to specify whether normal users are able to upload anything to the current directory room. If you set writable status to no, callers will not be able to transfer anything into the room. This command does not affect the Sysop or Co-Sysops. [Y]- toggle backbone status The backbone status command allows you to toggle backbone status on or off in the current shared room, for one or more network nodes. For details about backboning, see Section 8.4.2 [Topography and backboning], page 113. [Z]- autonetted room This command allows you to specify that the current network room should make all messages entered default to being networked, even if the authors do not possess network privileges. This is a dangerous setting to use in rooms that are shared with long-distance network nodes, since a little idiocy or vandalism could cost one or more Sysops a fair amount of money. 4.2.2 Message journalling There may be times that you wish to save a message or three to a normal text-file for use with some other program. The room archiving feature isn't suitable for this, so Fnordadel permits you to journal individual messages to a file located anywhere on your storage device(s). If the file is not empty, the message journalled will be appended to the file's end. A message may be journalled in three ways. To be precise: 1. While reading messages normally - Use normal message reading commands to display the desired message on screen, and [P]ause the output somewhere in the body of the message's text. Chapter 4: Aide and Co-Sysop Command Reference 73 - While the system is paused, hit `J' for [J]ournal. - The system will resume displaying the message through to its end, then redisplay and ask you to confirm that this is the one you want. - Assuming the message is the right one, answer `yes' and then give the system the path name of the file in which to save the message. Voila. 2. While reading messages using `more' - Since the above method can be cumbersome, or downright difficult in the case of small messages that scroll by before you can pause the system, you may also select the [J]ournal command from the .R(ead) M(ore) prompt. - The rest proceeds as above. 3. Using a modifier to the .R(ead) command - Any number of messages may be journalled in one swell foop using a modifier with the .R(ead) message-reading commands. The modifier is J(ournal). For example, `.RJN' will journal all new messages in the current room. - Using the J(ournal) modifier with .R(ead) will cause the system to prompt for a file name in which to save the messages retrieved. 4.2.3 Promoting local messages to net messages The Sysop and Co-Sysops have another special command available in the `more' menu (see Section 3.6 [More Mode], page 59), called pr[O]mote (`P' was already taken...). This command makes a new copy of the current message in the current room, and sets it up as a networked message. The room must be a shared room, and the message must be a local message, or Fnordadel will complain at you. Also, the command currently doesn't work in Mail>. 4.2.4 Sysop file transfers Normal users may only upload files to the system one at a time, but any user with Sysop or Co-Sysop status is permitted to upload multiple files in one .E(nter) command using batch file transfers. Batch uploads can be done using either X(modem) or Y(modem) modifiers to activate the obvious protocols. For example: .E(nter) Y(modem) B(atch). The reason batch uploads are disabled for regular users is that Fnordadel will blindly overwrite any previously existing file if a new one of the same name is sent during the batch transfer. A user of Sysop or Chapter 4: Aide and Co-Sysop Command Reference 74 Co-Sysop calibre is assumed to know what he/she is doing, but be careful not to wipe out files by accident. Two other things the Sysop and Co-Sysops can do regarding file transfers are upload into directory rooms that are set to `non-writable', or download files from directory rooms that are set to `non-readable' See Section 4.2.1 [Sysop room-editing commands], page 70. 4.2.5 Sysop doors Doors can be set up such that only a user with Sysop or Co-Sysop status can run them. Also, on any door that takes arguments, those users are not prevented from entering arguments that include the `:' and `\' characters. Normal users are prevented from using these characters to preserve the security of your storage device(s) from sneaky people trying to get at files in other drives or directories. See Chapter 9 [Doors], page 126. 4.2.6 Sysop mail differences The Sysop and Co-Sysops are not charged any net credits for long-distance mail. Watch out where your Co-Sysops (if you have any) are sending all those messages! See Section 5.2 [User Status Commands], page 80, for the command to assign credits to other people who need them. Another minor benefit for the Sysop and Co-Sysops shows up in conjunction with the [R]eply command in the .R(ead) M(ore) menu (see Section 3.6 [More Mode], page 59). Normally when a user tries to [R]eply to a piece of net-mail, if your system can't figure out where the reply should be sent, it will abort with an error. This forces the user to manually enter the message using `.EN', assuming he/she can figure out where the mail should go. The Sysop and Co-Sysops, however, are prompted by the system (after the failed [R]eply command) to enter an over-ride delivery address for the mail. If that address is known to your system, the reply proceeds as normal. See Section 8.5.1 [Net addresses], page 118, for all the goop on addressing net mail. 4.2.7 Aide and sysop room access Co-Sysops are allowed to forget rooms like normal users, but they are also allowed to get into any room (including invitation-only ones) if they know the full room name.