wiki ne pas soudainement trac logins

Question

J'ai un wiki qui semble trac ont décidé de ne pas autoriser les connexions. La sélection de "login" n'amène même pas les utilisateurs dans les zones de texte qui leur permettent d'entrer leurs informations de connexion. Au lieu de cela, il semble y avoir un délai d'attente, après quoi le navigateur présente les éléments suivants:

Traceback (most recent call last): 
    File "build/bdist.linux-x86_64/egg/trac/web/api.py", line 436, in send_error 
    File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 803, in render_template 
    File "build/bdist.linux-x86_64/egg/trac/web/api.py", line 212, in __getattr__ 
    File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 298, in _get_session 
    File "build/bdist.linux-x86_64/egg/trac/web/session.py", line 162, in __init__ 
    File "build/bdist.linux-x86_64/egg/trac/web/session.py", line 183, in get_session 
    File "build/bdist.linux-x86_64/egg/trac/web/session.py", line 62, in get_session 
    File "build/bdist.linux-x86_64/egg/trac/db/util.py", line 65, in execute 
    File "build/bdist.linux-x86_64/egg/trac/db/sqlite_backend.py", line 78, in execute 
    File "build/bdist.linux-x86_64/egg/trac/db/sqlite_backend.py", line 56, in execute 
    File "build/bdist.linux-x86_64/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error 
OperationalError: database is locked 

La base de données SQLite semble rester bloqué pendant toute la durée de cette tentative de connexion. J'ai essayé de reconstruire la base de données avec quelque chose comme:

echo .dump | sqlite3 existing.db | sqlite3 new.db 

mais le problème persiste. Nous l'utilisons en utilisant le serveur web plutôt que tracd. Des idées pour résoudre ce problème, ou comment extraire les pages wiki et reconstruire les connexions utilisateur autour d'eux? Je cours sur CentOS. Cela me laisse perplexe car les choses semblent soudainement avoir cessé de fonctionner, et trac n'est pas vraiment mon principal domaine d'expertise.

Merci!

Answer 1

Je fixe cela, et a trouvé un meilleur moyen de procéder à l'avenir. J'ai fait une copie de la base de données:

$ cp /var/www/trac/db/trac.db ./new.db 

J'ai ensuite fait une liste des tables de la base de données en exécutant la commande .schema et l'analyser:

$ echo .schema | sqlite3 new.db | grep "CREATE TABLE" | awk '{ print $3 }' > tableList.new 

Le fichier tableList.new puis énumérés les tableaux:

attachment 
auth_cookie 
cache 
component 
enum 
milestone 
node_change 
permission 
report 
repository 
revision 
session 
session_attribute 
system 
ticket 
ticket_change 
ticket_custom 
version 
wiki 

Après farfouillé dans la base de données, il semblait que le problème était probablement dans les tables auth_cookie, session_attribu te, session, simplement parce qu'ils semblaient susceptibles d'avoir quelque chose à voir avec l'exploitation forestière. Alors, j'ai décidé de laisser tomber ces tables et les recréer. D'abord, je jetai tous les schémas dans la base de données sur une table par table base:

#!/bin/bash 

/bin/rm -rf newSchemas 
mkdir -p newSchemas 

while read tn 
do 

echo New $tn 
echo ".schema $tn" | sqlite3 new.db > newSchemas/$tn\.sql 

done < tableList.new 

exit 0 

Puis j'ai laissé tomber les tables et les recréés sous forme de tableaux vides pour ces trois tables:

#!/bin/bash 

cp -v new.db fix.db 
echo "DROP TABLE auth_cookie;" | sqlite3 fix.db 
echo "DROP TABLE session_attribute;" | sqlite3 fix.db 
echo "DROP TABLE session;" | sqlite3 fix.db 

cat newSchemas/auth_cookie.sql | sqlite3 fix.db 
cat newSchemas/session.sql | sqlite3 fix.db 
cat newSchemas/session_attribute.sql | sqlite3 fix.db 

exit 0 

Donc, ces trois tables étaient là, mais vides, dans la nouvelle base de données.

Je mets alors la base de données fixe en place:

$ /bin/mv -vf /var/www/trac/db/trac.db /var/www/trac/db/trac.db.Save 
$ /bin/mv fix.db /var/www/trac/db/trac.db 

et les connexions ont commencé à travailler.

Autres choses que j'appris - en plus du dumping des schémas, vous pouvez vider la SQL réelle pour créer les tables avec des données:

#!/bin/bash 

/bin/rm -rf newTables 
mkdir -p newTables 

while read tn 
do 

echo New $tn 
echo ".dump $tn" | sqlite3 new.db > newTables/$tn\.sql 

done < tableList.new 

exit 0 

Cela pourrait vous permettre de voir si des tableaux comportent des erreurs .

Et vous pouvez vérifier l'intégrité de votre base de données:

$ echo "PRAGMA integrity_check;" | sqlite3 new.db 
ok 

Vous pouvez même vider la base de données entière et recréer:

$ echo .dump | sqlite3 existing.db | sqlite3 fromDump.db 

La grande chose, cependant, est que la copie du * Les tables .db ne fonctionnent que si la base de données n'est pas accessible. Vraiment, vous devriez faire une sauvegarde avec:

$ trac-admin /var/www/trac hotcopy /var/www/tracBackup 

Pour que cela fonctionne, le répertoire/var/www/tracBackup ne devrait pas exister (il sera créé ). Cela verrouille la base de données pour la durée de la copie. Ensuite, vous sauvegardez/var/www/tracBackup et restaurez à partir de cela. La seule raison pour laquelle je suis allé dans et mucked avec la base de données est que je ne savais pas cela.