Backtalk often crashes when I try to open an item from the web 
interface. Should I post the dump that comes with the error page, or is 
it useless since there's no one able to debug Backtalk around any more?

24 responses total.

Try a different color scheme, maybe.  It used to do that to me a lot.
I have no idea why that would influence it, but it appears to based
on a lot of experimentation.  Even so, it still crashes for me
occasionally (just not all the time like it used to). If I recall
correctly, backtalk crash information is collected in /var/log or
a similar place.

Changing color schemes (I've tried several) doesn't seem to reduce 
crash frequencies. Global and conference-level functions seem OK, but 
the system tends to crash when I try to open individual conference 
items. It's so frequent that the web interface is almost unusable. THIS 
item is the only one I've been able to open from the web today.

Yeah, send the stack dump; I'll try and take a look at it.

Might be due to all the system updates we've done since it was
first written (like a decade or more back in time).  It would
be good if it can be fixed. People do use the web interface quite
a bit.  I tend to use the command line interface but sometimes
I use the web bbs just to do something different.

Crash seems to occur only when I am logged-on to the web interface. No log-on,
no crash.

Yes i am having the same problems also. It seems to crash on certain
conferences and not others. 

What I notitced you can read all areas anonymously but since you're not logged
in you can't post or respond. To me it's behaving like there's no javascript.
I know Backtalk doesn't use javascript. I'm just say'in. There's a "glitch"
somewhere in the code.

I'm conducting an experiment. I've changed the name of my ~/.cfdir 
directory so that to back- and fronttalk it looks like I've never used 
the conference system. Now I'm using the bt web interface (only) both 
anonymously and logged-in. I can read and post to conferences as ex
expected with no crashes so far.

In attempting to build and install bt, I realized that it is first and 
foremost a WEB-based conference system. This wasn't obvious to me 
because I first came to Grex looking for a shell-based community and
first  first started exploring the conferences from my shell account,
which means  means I was entering bt indirectly through the fronttalk
shell interf interface. 

My theory is that there are parts of bt (like the read status markers)
that that are designed with the assumption that the web interface will
be ever every user's first introduction to bt, and that using ft will
come late later, if ever. The crashes were happening because I'd
accessed the conf conferences first through ft, and it had set up my
status data in a way that that was incompatible with bt checking on my
status from the web.

If I continue to find no problems using bt from the web, the next step
is is to try ft again and see if it can nicely share the status data
that bt bt has initialized.

So far, so good using bt from the web.

Next, ft from the shell...

Fascinating.

On my shell account, I see that because of my access from the web bt has
 recreated my .cfdir and the read marker files inside with owner cfadm
and  group people but readable by others.

fronttalk sort-of works. I can browse conferences, and the "new" command
 takes me through conferences I added to my hotlist on the web. However,
I  can only read items in conferences that I haven't previously visited
in  bt, and the read marks don't get updated for items When I leave ft I
see  new read marker files in .cfdir/ for the conference I visited in
ft, but  its owner is me instead of cfadm.

It looks to me like the cause of the bt crashes and read marker problem
in  ft are both due to conflicting file permissions where bt creates
user  status files owned by cfadm but ft uses the player's own ID as
file owner.

Backtalk is subtle.

It's actually a programming language interpreter that was originally
intended to be interacted with via a web browser; however, that does
not mean that one *has* to use a web browser to interact with it.

Fronttalk, as I'm sure you've discovered, is a non-web frontend to
backtalk.  It's actually a perl program that opens a socket to the
backtalk interpreter and tells it to load a special, fronttalk
specific program (and run it).

I suspect what you're running into is permission issues, FWIW.

Subtle indeed.

After a little more poking around I have to modify my story slightly.

BT does not create the ~/.cfdir directory. For BT users who never use FT
FT, read marker files are kept by BT in it's own directory. ~/.cfdir is
cr created the first time you use FT from the shell, copying marker
files fr from BT's directory to ~/.cfdir. Permissions on ~/.cfdir are
711.

BT starts crashing after your first use of FT if you try to view an 
item in a previously unvisited conference while logged-on. It's because
i it's trying to create a read marker file for the new conference in
your ~ ~/.cfdir, but doesn't have permission to create the file since BT
is r running as user cfadm.

If I am correct, does that mean that we could solve the problem by ...

a) Modify FT to create each user's ~/.cfdir as user cfadm

- or -

b) Modify BT to run with suEXEC with the logged-in user ID so that all
re read marker and other status files and directories are initially cr
created with the user's own ID

???

- or -

c) Get BT and FT out of each other's hair and mirror user read markers 
and other status in both BT-space and FT-space (user ~/.cfdir). Then wh
when either BT or FT starts they first check if the user's status on th
the opposite side is more recent than its own, and if so synchronizes it
its status. It would eliminate the need for the twins to be writing fi
files in directories originally created by the other twin.

This would take more coding than a) or b), and worst-case-scenario is 
that it would take twice the disk space to store user read status (but 
that take so much space?), but at first blush this feels like it might 
be the right thing to do.

Incidently, deleting ~/.cfdir and accessing the conferences with Fronttalk
only without using logging in to BT on the web appears to solve the FT read
marker file ("participation file" in BT docs) problem.

resp:14 I think that if you're using fronttalk and don't care about the
web interface, you don't need to do much special: just run it.

I think it's a compile-time option to tell it where to store
participation files, etc. By default it does it in it's own
tree, but you can tell it to use $HOME/.cfdir.  I forget how,
though....

resp:16 Re. FT, I think you're right. Re. compile options, I will continue
experimenting. I should figure out how to run Apache on my Slackware box so
I can try out options that require root authorization.

To summarize what I have found for others who are experiencing crashes on the
BT web interface and/or FT from the shell (`bbs`) not remembering which items
you've read: BT and FT are having file permission-related problems when
trying to save or read user status data. It's not yet clear whether this is
a code problem or a configuration problem, but there is a work-around:

1. Rename or delete the subdirectory .cfdir in your home directory. If 
renaming, the new name can be anything other than ".cfdir". If deleting 
you will have to first delete all the files in the subdirectory or use 
`rm -rf`. If your .cfdir subdirectory contains the files .cflist and/or 
.cfonce, you might want to save copies of them in order to restore your 
conference hotlist and configuration.

2. Choose one interface, shell or web, and stick with it. If you want to 
access the conferences from your shell account (with the command `bbs`), 
do not log in to the web interface (though you can still read 
conferences on the web in anonymous mode). If you want to participate in 
conferences via the web, do not use the shell interface.

3. If you choose the shell interface, run `bbs` and read at least one 
item in the Agora conference then quit. FT will automatically (re)create 
subdirectory .cfdir in your home directory. If you saved copies of 
.cflist and/or .cfonce in step 1., copy/move them into your new .cfdir 
subdirectory to restore your hotlist and FT configuration.

4. If you choose the web interface, open the web page, log in, and use 
the system as normal. If you had a hotlist, you will have to recreate 
it.

Other than having to give up one of the conference interfaces, the 
biggest draw-back to the workaround is that your reading history will be 
lost and you will have to catch-up on all the old conferences.

Unreadable Politics item #123
http://grex.org/cgi-bin/backtalk/peek:politics
http://grex.org/cgi-bin/backtalk/pistachio/confhome?conf=politics
http://grex.org/cgi-bin/backtalk/peek:politics:124
http://grex.org/cgi-bin/backtalk/peek:politics:131
but http://grex.org/cgi-bin/backtalk/peek:politics:123

resp:18
The Backtalk (shell interface) BROWSE command shows that Politics conference
item 123 doesn't exist. Probably deleted by the original poster.

j politics works.

This response has been erased.

resp:21 Good work! Thank you.

It would be great if great if we can get Fronttalk and Balktalk compatible
with each other so users could use either or both interfaces.

2nd pass of response 21:  I encountered the backtalk crash error.  I
walked through the investigation above and came up with the following
...

Current state
(1) fronttalk (cli) creates the ~/.cfdir directory 
    with mode 755 and ownership <user>:people.

(2) fronttalk (cli) creates files under ~/.cfdir 
    with mode 644 and ownership <user>:people.

(3) backtalk (web) creates files under ~/.cfdir
    with mode 644 and ownership cfadm:people.

(4) Backtalk (web) logon & use results in crash errors if ~/.cfdir
    or any file below are not rwx for backtalk (web).
    I.E. files created by fronttalk (cli).

Work-a-round * 
(1) Manually change the mode of ~/.cfdir so backtalk (web) can access:
    $ chmod 777 ~/.cfdir

    *  Yes, some bad user can now delete or change the 666 files.
       Not really much at stake here (backup if concerned).

(2) To make files under ~/.cfdir accessible to fronttalk (cli) 
    and backtalk (web)
    change ownership to <user>:people and mode set to 666.
    Users cannot set mode to 666 on files owned by cfadm.
    Users can replace these files instead per below.

    Script to do this: talk-fix.bash
    #!/usr/local/bin/bash
    mkdir ~/.cfdir/ZTMP
    find  ~/.cfdir -type f -user cfadm -exec cp {} ~/.cfdir/ZTMP \;
    find  ~/.cfdir/ZTMP -type f -exec mv -f {} ~/.cfdir \;
    find  ~/.cfdir -type f -exec chmod 666 {} +
    rmdir ~/.cfdir/ZTMP

(3) Rerun the script before using of fronttalk (cli) 
    if backtalk (web) was used previously.

    Rerun the script after using fronttalk (cli) 
    if backtalk (web) will be used subsequently.

    Or only use either the cli or web interface as discussed above.

Fixes that seem needed
(1) backtalk (web) should create ~/.cfdir if missing with ownership 
    <user>:people.

    Or at least: 
    /etc/skel should include .cfdir so it is present for backtalk (web).
    That is, the user does not need to open fronttalk (cli) in order 
    for creation of ~/.cfdir.
 
(2) backtalk (web) should create files with ownership <user>:people.

I will update again if I learn more.

More on the back/front talk .cfdir access errors and partutil

**problem
  described above

**background info**
unixpapa.com/backtalk/stab/doc/glossary.html
Partutil Program
The partutil program is used only on systems where real Unix accounts
are used and Backtalk is to cooperate with Picospan or Yapp [or
fronttalk]. In this case, the files stored in the user's home directory
are owned by the user, and thus not writable by the Backtalk program.
The partutil program is a work-around for this problem. It is an
suid-root program which can be called by Backtalk to creates or destroys
these files, and to permit the to be writable to a Backtalk's Unix
group-ID. Various safeguards are built-in to prevent partutil from being
run by anyone other than Backtalk. 

CURRENT mode for partutil
grex$ for f in $(locate partutil); do ls -l $f; done
-rws--x--x  1 root  cfadmg  /suid/libexec/partutil
lrwx------  1 root  wheel   /suid/libexec/partutil-1.3.30 -> partutil
lrwxr-xr-x  1 root  wheel   /cyberspace/libexec/backtalk-1.3.30/partutil

                           -> /suid/libexec/partutil-1.3.30

**mode testing
SUID mode tests on Linux (I don't have an OpenBSD install.)
The files below are here: http://grex.org/~bwh/suid.tgz

user1@I660> pwd
/opt/suid

user1@I660> ls -l
total 24
lrwxrwxrwx. 1 root root  addent_suid_target -> suid_script_wrapper
-rwx------. 1 root root  suid_script.bash
-rwsr-xr-x. 1 root root  suid_script_wrapper
-rw-r--r--. 1 root root  suid_script_wrapper.c
-rw-r--r--. 1 root root  suid_target

**suggestion
change mode of /suid/libexec/partutil to -rwsr-xr-x (4755) 
instead of -rws--x--x (4711)

And, maybe the mode of this link:
lrwx------  1 root  wheel   /suid/libexec/partutil-1.3.30 -> partutil
should be lrwxr-xr-x (Linux sym links are lrwxrwxrwx and permissions of
the linked file are used.)

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss