====== Miscellaneous ====== Answers to miscellaneous Frequently Asked Questions regarding Synchronet. * [[#deleted_msgs|Why is it that deleted messages still appear in message bases]]? * [[#new_user_questions|How do I disable New User prompts/questions]]? * [[#new_user_feedback|How do I disable the New User Feedback requirement]]? * [[#no_guest|How do I disable the Guest user account]]? * [[#sbbslist|How do I get my BBS listed on the Synchronet BBS List]]? * [[#time_stamp_error|Why am I getting a "Daily stats time stamp" error]]? * [[#migration|How can I migrate my Synchronet configuration and data to another computer]]? * [[#max_msgs|Why are there more messages in my message base than the configured maximum number of messages for that sub-board in SCFG]]? * [[#qnet_tag|Why doesn't my QWK networking tagline appear on my posted messages]]? * [[#ftn_msgid|Why do my FidoNet MSGID's look different than someone else's]]? * [[#old_baja|Why won't an old Baja source file compile without errors]]? * [[#sizeof_scfg|Why do I get this error about cfg->size != sizeof(scfg_t)]]? * [[#spell|How do I spell "Synchronet"]]? * [[#abbreviate|How do I abbreviate "Synchronet"]]? * [[#syncterm|How do I report a problem or request a feature for SyncTERM]]? * [[#k:line|What is an AKILL on IRC and why was I K:Lined]]? ===== Deleted Msgs ===== :?: **Question:**\\ Why is it that deleted messages still appear in message bases? :!: **Answer:**\\ In Synchronet, when a message is deleted, it is only flagged for deletion. The actual removal of "deleted messages" from message bases takes place during regularly scheduled message base maintenance (using the [[util:smbutil]] utility). Normally, messages flagged for deletion will have a **DELETED** attribute displayed in the message header, if/when the message is displayed to a user. Messages flagged for deletion may be "undeleted", but only when they are visible to a user or sysop. There is a Synchronet configuration option, [[util:SCFG]]->Message Options->Users Can View Deleted Messages, with three possible settings: - Yes - No - Sysops Only If the sysop wants deleted messages to appear to be immediately and permanently removed from the message base, they should set this option to "No". When this option is set to "Yes", all users with read-access to the message base will be able to view/read messages flagged for deletion. When set to "Sysops Only", this option will only allow messages flagged for deletion to be visible to system operators (sysops) and sub-booard operations (sub-ops). Note: Deleted messages may still be viewed and undeleted using the [[util:smbutil]] program and possibly other methods, until the deleted messages are actually removed from the message base during maintenance. ===== New User Questions ===== :?: **Question:**\\ How do I eliminate one or more prompts or questions during new user sign-up? :!: **Answer:**\\ Many of the "New User" Questions can be disabled by setting various options in [[util:SCFG]]->System->New User Prompts... to "No": ╔══════════════════════════════════╗ ║ New User Questions ║ ╠══════════════════════════════════╣ ║ │Real Name Yes ║ ║ │Force Unique Real Name No ║ ║ │Force Upper/Lower Case Yes ║ ║ │Company Name No ║ ║ │Chat Handle / Call Sign Yes ║ ║ │Force Unique Handle / Call No ║ ║ │E-mail/NetMail Address Yes ║ ║ │Sex (Gender) Yes ║ ║ │Birthday Yes ║ ║ │Address and Zip Code No ║ ║ │Location Yes ║ ║ │Require Comma in Location No ║ ║ │Phone Number No ║ ║ │Allow EX-ASCII in Answers Yes ║ ║ │External Editor No ║ ║ │Command Shell Yes ║ ║ │Default Settings Yes ║ ║ │Color Terminal No ║ ╚══════════════════════════════════╝ Other "New User" prompts/questions can be disabled by finding their corresponding string in your ''[[dir:ctrl]]/[[custom:text.dat]]'' file and changing it to an empty string (i.e. ''""''), e.g. ''MouseTerminalQ'', ''EnterYourAlias''. ===== New User Feedback ===== :?: **Question:**\\ How do I eliminate the requirement that new users send feedback/mail to the sysop during sign-up? :!: **Answer:**\\ In Synchronet for Windows, run the Configuration Wizard and un-check the "Require new user feedback" check-box. Or, set [[util:SCFG]]->Nodes->Node 1->Advanced Options->Validation User to "0" (Nobody). If you want your new user validation feedback (e-mail) to go to another user, enter that user's number here. ╔══════════════════════════════════════════════════════════╗ ║ Advanced Options ║ ╠══════════════════════════════════════════════════════════╣ ->│Validation User Nobody <- ║ │Notification User 1 ║ ║ │Notification Error Level Error ║ ║ │Semaphore Frequency 5 seconds ║ ║ │Statistics Frequency 5 seconds ║ ║ │Inactivity Warning 300 seconds ║ ║ │Inactivity Disconnection 600 seconds ║ ║ │Daily Event ║ ║ │Text Directory ..\text\ ║ ╚══════════════════════════════════════════════════════════╝ In Synchronet v3.20, this setting has moved to [[util:SCFG]]->System->Notifications->New User Feedback: ╔═════════════════════════════════╗ ║ System Operator Notifications ║ ╠═════════════════════════════════╣ ->│New User Feedback Nobody <- ║ │Error Notifications User #1 ║ ║ │Error Level Error ║ ╚═════════════════════════════════╝ ===== No Guest ===== :?: **Question:**\\ How do disable the Guest user account on the BBS? :!: **Answer:**\\ You don't have to have a Guest (G-[[access:restrictions|restricted]] user) account. If you don't create a Guest account to begin with, you won't have one. If you created a Guest account and you don't want it, then simply deleting the user account from the user base will work. However, without a Guest account, anonymous FTP access will not be available and some web UI elements may not function as is normally expected. To keep the Guest account but disallow logins to the Terminal Server (the traditional BBS user experience), set [[util:SCFG]]->Nodes->Node X->Logon Requirements->Requirement String to: NOT GUEST Doing this will cause terminal logons as "Guest" to be rejected with the following (configurable) message: You do not have sufficient access for this node. **Note:**\\ You can remove the ''or 'Guest''' text from the [[module:login]] module's ''Login:'' prompt, even if the Guest user account exists, by setting ''guest=false'' in the ''[login]'' section of the ''[[dir:ctrl]]/[[config:modopts.ini]]'' file. This login module setting does not impact a user's ability to login to the Terminal Server as //Guest//. ===== SBBSList ===== :?: **Question:**\\ How do I get my BBS listed on the [[http://synchro.net/sbbslist.html|Synchronet BBS List]]? :!: **Answer:**\\ The best way is to first join [[network:DOVE-Net]], then run the Synchronet BBS List ([[module:sbbslist]]) door on *your* BBS and add an entry for your BBS. This entry should be automatically exported to the DOVE-Net SYNCDATA echo which will then be propagated to [[bbs:Vertrauen]] and every other BBS on DOVE-Net. The ''[[http://synchro.net/sbbslist.html|sbbslist.html]]'' page is automatically generated on Vertrauen every night at midnight (Pacific time), so wait a day or so for your entry to appear on the list. You can also check a dynamically generated HTML BBS list [[http://cvs.synchro.net/sbbslist.ssjs|here]] or [[http://web.synchro.net/?page=More/999-sbbslist.xjs|here]]. If it doesn't appear, verify that that your BBS entry was properly exported (as a message) to the SYNCDATA message area. The timed events SMB2SBL and SBL2SMB that will import and export BBS entries should be configured by default. If they are not, see [[module:sbbslist]] for more details. ===== Time Stamp Error ===== :?: **Question:**\\ Why am I getting the following error when running SBBS? source: logon.cpp action: checking object: Daily stats time stamp :!: **Answer:**\\ Because your system's date/time has been adjusted **backwards** more than 24 hours. - Shutdown the BBS - Fix your system date/time - Edit ''[[dir:ctrl]]/dsts.ini'', change the "Date" value to yesterday's date - Restart the BBS ===== Migration ===== :?: **Question:**\\ How can I migrate my Synchronet configuration and data to a new computer? :!: **Answer:**\\ You can simply copy the Synchronet directory tree (e.g. ''C:\SBBS''), complete with all sub-directories, to the new computer, even if the new computer is running a different operating system! Synchronet doesn't **require** //installation// on a computer, but if you wish to, you can [[:install:]] Synchronet on the new computer and then simply over-write the newly-installed files with your old/migrated files, provided they are the same version of Synchronet. If the old computer was running a different (older) version of Synchronet than the version installed on the new computer, then it's likely best to upgrade the old version (if you can) on the old computer before migrating to the new one, though this is not strictly required. If the target (new) computer is running Windows and you choose not to install, then you may want to create a shortcut to ''sbbsctrl.exe'' in your Windows ''Startup'' folder (so it will automatically run when you login) and/or install the [[:monitor:ntsvcs|Synchronet NT Services]] (which can run without logging-in as a user). If the target computer is running Windows //Vista// or later, then you'll also want to follow the solution to this [[:faq:win#sbbsexecdll|FAQ]] as well. For 16-bit DOS program support, the Synchronet Windows NT FOSSIL driver (''sbbsexec.dll'') must also be copied to the Windows ''System32'' folder. See [[/faq:win#sbbsexecdll|the sbbsexec.dll FAQ]] for details. If the source (old) computer was running Windows and you wish to preserve any changes you made to the [[:monitor:sbbsctrl|Synchronet Control Panel]] settings (stored in the Windows registry), you can export those settings to a ''sbbsctrl.ini'' file (using the File->Export Settings menu option) and then import them into the Synchronet Control Panel running on the new computer (using the File->Import Settings menu option). These settings include some changes made via the File->Properties menu. Settings made in most other menus in the Synchronet Control Panel are stored in your ''[[dir:ctrl]]/[[:config:sbbs.ini]]'' file. If the source (old) and target (new) computers are both running a Unix-like operating system (e.g. Linux), be sure to rebuild *all* the native executable binaries (''e.g. libsbbs.so''), including 3rd party libraries (e.g. ''libcl.a'') on the new/target computer before trying to execute them. Failure to do so could result in "invalid opcode" errors. Configuration changes made via the ''[[:util:SCFG]]'' utility are stored in the ''*.ini'' (previously, ''*.cnf'') files in your ''[[dir:ctrl]]'' directory. If you wish to **only** migrate configuration and data files (e.g. over an new installation of Synchronet), copy (recursively) the following Synchronet sub-directories to the new computer: * ''[[dir:data]]'' * ''[[dir:ctrl]]'' * ''[[dir:node]]*'' If you customized any of your filter (''*.can'') or menu (e.g. ''*.asc'', ''*.msg'') files, you'll also want copy (recursively) the following directory: * ''[[dir:text]]'' If you customized any of your executable modules (e.g. ''*.js''), you'll also want copy the following directory: * ''[[dir:mods]]'' If you installed any new doors in the ''xtrn'' directory or your users used any of the stock-installed doors and you'd like to retain that data, you'll also want to copy the following directory: * ''[[dir:xtrn]]'' **Note:** Sysop-installed (e.g. not from [[:dev:Git]]) or modified modules should not normally be stored in your ''[[dir:exec]]'' directory, but if they were, then you'll want to copy those over as well. ===== Max Msgs ===== :?: **Question:**\\ Why are there more messages in my message base than the configured **maximum number of messages** for that sub-board in [[util:SCFG]]? :!: **Answer:**\\ The maximum number of messages configured via SCFG->Message Areas ... Sub-boards (and visible when using the ''[[util:smbutil]] s'' command as the ''max_msgs'' value) is enforced when the message maintenance (e.g. ''smbutil m'' command) is executed. By default, Synchronet comes with a pre-configured //Timed Event// called ''MSGMAINT'', set to run weekly, which will perform normal message base maintenance on all of the message bases in your ''[[dir:data]]'' directory, including the deleting of old messages, if necessary, to meet the configured "Maximum Messages" value. Timed events may also be forced by the sysop to run immediately at any time, if desired. ===== QNET Tag ===== :?: **Question:**\\ Why doesn't my configured QWK networking tagline (or FidoNet Origin line) appear on my locally posted messages? :!: **Answer:**\\ QWK network taglines (and FidoNet Origin lines) aren't added to messages until they are exported to a message network. The locally posted messages will not have QWKnet taglines (or FidoNet Origin lines). **Note:** You can see what your configured QWKnet tagline (or FidoNet Origin line) looks like by using the ''I'' (sub-board information) command. ===== FTN MSGID ===== :?: **Question:**\\ Why do the FidoNet-style Message-IDs for messages created-by or posted-on Synchronet BBSes appear different than the Message-IDs of messages posted by other FidoNet-type nodes? :!: **Answer:** (sorry this is a long and possibly contentious answer)\\ Because, for the message-IDs to be useful for any intended purpose (e.g. dupe-checking, reply-linking) they **must** be //unique// for every message created on a BBS. When using [[https://www.ietf.org/rfc/rfc0822.txt|Internet-standard message-IDs]] (defined in 1982), this is not a problem because the entire message identifier is basically free-form text (between ''<'' and ''>'' delimiters), leaving the entire data portion completely up to the implementer (e.g. programmer) to add whatever data they feel necessary to guarantee a unique ID for any particular message created at any given time. No data within an Internet-standard message-ID is expected to be interpreted or used in any way, other than to uniquely identify a particular message. The data could be a large number or just a string of meaningless symbols and so long as it is unique, it's doing its job rather perfectly. Usually, an Internet-standard message-ID will contain a globally unique addresses (e.g. public IP address or host name) so as to prevent random collisions with the IDs generated on a nearly unlimited number of other systems on the Internet, but there is no //requirement// that an address is included in the identifier. However, for FidoNet, [[http://ftsc.org/docs/fts-0009.001|the de facto standard]] (defined in 1991) imposed some restraints on the contents of its message-IDs (the data between ''^AMSGID: '' and ''CR'' delimiters): 2 fields separated by a single space: **''origaddr''** and **''serialno''**. The definition of the ''serialno'' field is thus: ... may be any eight character hexadecimal number, as long as it is unique - no two messages from a given system may have the same serial number within a three years. My interpretation of this requirement is that the author of the specification was asserting that 32-bits (8 hex digits) of data (~4.2B unique numbers) was enough to uniquely identify every message generated on a single FidoNet node for at least 3 years. Even if that assertion were true, as an experienced BBS software developer, I have these issues with that concept: - 3 years is not long enough. I have message threads on my BBS dating back 20 years or more and I certainly expect and my software depends on the message-IDs being unique so long as the messages are stored in the message bases. If the messages are stored for a 100 years, their identifiers should still be unique then. So forget the 3 year clause, that's no more valid a limitation than Bill Gates' 640 Kilobytes((supposedly a myth, but a good one)). - A pseudo-randomly chosen 32-bit number is obviously **not** a good choice, but it //would// probably work for the majority use case. I fear that some inexperienced or lazy programmers might have chosen this simple "solution" and no one would be the wiser until... someday there's a random ID collision and someone might notice and complain. But probably not. - A 32-bit ''time_t'' (Unix time, in seconds since Jan-1-1970) would seem an obvious choice for the ''serialno'' field except for the fact that today's systems can generate many thousands of messages //per second// if they need to. Even the multinode systems of the 80's and 90's could easily generate multiple messages within the same second. Many FidoNet programmers fatally chose a ''time_t'' value as their ''serialno'' and only source of //uniqueness// and you can see the proof of this in the MSGIDs that show up in FidoNet messages //to this day//((If this is your software doing this, you should fix or replace it)). Again, nobody is wise to this design flaw until there is a "random" collision one day... and maybe someone notices. But usually not. - A system to exclusively register monotonically-incrementing message serial numbers would be error prone (e.g. the sysop deletes the data file tracking the last assigned serial number) and unnecessarily bottle-neck message generation (e.g. importing thousands of messages from some other networking technology, which would need unique FidoNet-style message-IDs assigned to each). - It's obviously still a problem if 2 //different// systems generate the same message-ID ''serialno'' value, unless there's some //other// source of "uniqueness" in the Message-ID... Which brings us to the ''origaddr'' field which is defined in FTS-9 as: ... should be specified in a form that constitutes a valid return address for the originating network. Now //this// identifier field has some promise: - It's not limited to a specific number of characters or a specific character set. - It's rather vague about what constitutes "a valid return address". - It's only a "should" clause, which in spec-lawyer-speak, means: "you don't //[[http://ftsc.org/docs/fta-1006.002|have]]// to" (in contrast to "shall" or "must"). So the ''origaddr'' is where Synchronet and its utilities (e.g. [[util:SBBSecho]]) adds unique data to insure that all messages generated by a correctly-configured Synchronet system have //unique// FTN message-IDs... forever. The data we place in the ''origaddr'' is currently thus: .@ where * '''' is the monotonically-incrementing message number for the message in this particular message database (//echo area//) * '''' identifies the system-local message database where the identified message is stored * '''' is the 3D or 4D FTN-style address of the FidoNet-style node that created the message Example: 73470.sync@1:103/705 The result **is** a "//valid return address for the originating network//", in that a FidoNet NetMail sent to this address will normally reach the sysop of the originating node (in the example case, me). But the //originating// network might **not** be an FTN network. There is **nothing** in FTS-9 that specifies the form or content of the ''origaddr'' field. In fact, it mentions the use of "double-quotes" and how they must be escaped if part of the address. When is the last time you saw quotes of any kind in an FTN address? Clearly the author was leaving this definition open to non-FTN addresses. And again, it's only a "should" clause anyway. This field could only contain the GPS coordinates of my birthplace and would still be completely within the requirements of the specification. The serial number (''serialno'') field generated by Synchronet and its utilities is a mathematical sum of the area-unique '''' and a number derived from the date and time the message was created so as to maximize the use of the allocated 32-bits. The serial number will be unique among all the messages generated by a Synchronet-system in a single message area (echo), but is not guaranteed to be unique, by itself, among //all// the FTN-connected message areas of a single Synchronet-system. The ''serialno'' field //alone// does **not** constitute a unique message identifier, so don't try to use it as one! **But it doesn't //look// like other other FTN MSGID's!?!** This is true. But before [[person:digital man|I]] decided on the makeup of the Synchronet-generated FTN MSGID's I collected and collated many thousands of FidoNet messages from the Zone 1 backbone echoes and found that there was already a lot of variety in the //look// of the ''orginaddr'' field of the MSGIDs used over the last 20+ years: Most were simple 3D or 4D FTN-style addresses, but many had 5D-style addresses with ''@fidonet'' as the domain, sometimes ''@fidonet//.org//'', and many others just had what appeared to be an Internet-style host name (no ''@'' or FTN-style address at all). Others combined Internet-style host names with other seemingly random or incrementing numbers or symbols. So Synchronet/SBBSecho did not introduced some "new thing" into FidoNet. Indeed, I would just be the next thoughtful programmer that has solved this problem in his or her own way because the original specification (FTS-9) was short-sighted((RFC-822... anyone, anyone?)) and **never fixed**. If you have or know of someone that has software that has a problem with the Synchronet-generated FTN MSGID's, I am truly sorry. That same software, if it exists, would have a similar problem, whatever that is, with many other unique FTN MSGID's which existed long before Synchronet and SBBSecho started sending messages with unique message-IDs into FidoNet-style networks. **But //why// don't you change it to look like other FTN MSGID's!?!** Because: - That would defy the uniqueness of the FTN MSGID's generated by Synchronet, and that's the **entire point** of their existence. - If I were motivated to change how the MSGIDs look, it would be to make them **more** unique, not //less//. - The MSGIDs are **already compliant** with the requirements of the //de facto standard// specification ([[http://ftsc.org/docs/fts-0009.001|read it]]), so they don't need to be changed. - The MSGIDs are not //that// dissimilar to unique MSGIDs that have been included in FidoNet messages posted by other compliant-software for **over 20 years**. - You should fix or replace **your software** instead. :-P ===== Old Baja ===== :?: **Question:**\\ Why do I get the following error when compiling an old [[util:Baja]] source (''*.src'') file: ''!SYNTAX ERROR (expecting integer constant)''? :!: **Answer:**\\ Most likely, the Baja source file references numeric constants using symbolic names (e.g. ''UM_EXPERT'') which *used* to be hard-coded in to the Baja compiler, but aren't any longer (since Baja v2, circa 1995). These numeric constants were moved to the Baja //include file// named ''sbbsdefs.inc''. The solution is to add the following line near the beginning/top of the old Baja source file in question: !include sbbsdefs.inc **Note:** To see a complete list of changes in Baja v2, see {{http://synchro.net/docs/baja2new.txt}}. ===== sizeof scfg ===== :?: **Question:**\\ Why do I get the following error when running a Synchronet program: ''cfg->size(x) != sizeof(scfg_t) (y)''? :!: **Answer:**\\ The program you're trying to run (e.g. ''sbbs'', ''sbbsctrl'', ''jsexec'') was built from a different version/revision of the Synchronet code base than the Synchronet library: ''sbbs.dll'' (on Windows) or ''libsbbs.so'' (on UNIX) it's loading from disk. Look for extra/additional Synchronet library files and executables on your file system (e.g. in your Synchronet ''[[dir:exec]]'' directory?) and remove or rebuild them. ===== Spell ===== :?: **Question:**\\ How do I spell "Synchronet"? :!: **Answer:**\\ With an '**h**'. You can CamelCase the "Net" in "Synchronet" if you strongly prefer, but since there are a few companies/services which have trademarked that name (with a capitalized "Net"), it may be confusing. It's been just "Synchronet" (like "Internet") for over 20 years now, so it should probably just stay that way. **Note:** This isn't actually a frequently asked question, but it should be. ===== Abbreviate ===== :?: ** Question:**\\ How do I abbreviate "Synchronet"? :!: **Answer:**\\ With**out** an 'h'. :-) Seriously, the full name is "Synchronet BBS Software", so we prefer to usually abbreviate that to either 'SBBS' or just 'Sync'. Since 'Sync' is pronounced with one syllable and 'SBBS' is four, sometimes that's a reason to prefer 'Sync' to 'SBBS'. 'Synch' looks like 'sinch' or 'cinch', so that abbreviation should be avoided. **Note:** This isn't actually a frequently asked question, but it should be. ===== SyncTERM ===== :?: ** Question:**\\ Where do report a bug or request a feature of SyncTERM? :!: **Answer:**\\ On sourceforge.net, [[https://sourceforge.net/p/syncterm/feature-requests/|feature requests]] and [[https://sourceforge.net/p/syncterm/tickets/|bug reports]]. ===== K:Line ===== :?: ** Question:**\\ What is an AKILL on IRC and why was I K:Lined? :!: **Answer:**\\ AKILL is a feature of IRC services that will distribute a K:Line to all the other servers in the network. A K:Line is a server ban for your specific hostname or IP address. This means if you are AKILLed then you're banned from every other server. This is done to protect the network from spambots, flooders, and continually disruptive elements. AKILLs are done either manually by a Services Operator, or automatically by use of various methods employed by the IRCops. If you believe you have been accidentally or unfairly AKILLed from the Synchronet IRC network, contact sysop@endofthelinebbs.com with your IRC nickname, ip address, hostname (if you have one), date and time, including timezone, and any other relevant details. ===== See Also ===== * [[:faq:|Frequently Asked Questions]] {{tag>misc faq}}