Custom Query (196 matches)
Results (58 - 60 of 196)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #113 | fixed | Django auto-installs on a machine where USER != ATHENA_USER get wrong email address | adehnert | adehnert |
| Description |
Currently, the Django auto-installer bakes the username of the running user into settings.py as the email address in the ADMINS variable. On a debathena-standard machine where $USER and $ATHENA_USER don't match, this will result in mail relating to your autoinstall going to $USER@… instead of $ATHENA_USER@…. This seems unfortunate. So far as I can tell, the semantics of the "human" argument to the onserver scripts is something like "Athena username". Assuming that's the case, I think the patch below will fix this bug, though I'm not actually sure how to test it, so I haven't. Index: locker/deploy/bin/onathena
===================================================================
--- locker/deploy/bin/onathena (revision 1454)
+++ locker/deploy/bin/onathena (working copy)
@@ -256,7 +256,7 @@
fi
cd "$origdir"
-vsshrun "deploy$scriptsdev/bin/$deploy" "$sname" "$deploy" "$addrend" "$admin_username" "$requires_sql" "$scriptsdev" "$USER" || die "Unknown failure during configuration"
+vsshrun "deploy$scriptsdev/bin/$deploy" "$sname" "$deploy" "$addrend" "$admin_username" "$requires_sql" "$scriptsdev" "${ATHENA_USER:-$USER}" || die "Unknown failure during configuration"
rm -f "$lroot/web_scripts/$addrend/.scripts-tmp"
checkfailed
|
|||
| #114 | fixed | better story for importing outside Django sites | geofft | |
| Description |
We do a lot of custom stuff in setting up Django -- splitting between web_scripts and Scripts/django, tweaking the FastCGI wrapper, setting up MySQL in settings.py, etc. This all makes it really easy to start a Django site from scratch, but makes it nonobvious to import a Django site you developed on your local machine with the built-in server. Options to address include restoring the deleted scripts FAQ on manually setting up Django, so you can do those instructions by hand, and writing a script to scriptsize an existing Django directory. |
|||
| #115 | fixed | actively break sudo for users who aren't supposed to | geofft | |
| Description |
PAM is a good choice here. So is replacing our uses of sudo internally (like LDAP backups from the scripts locker) with setuid wrappers, and making sudo not setuid a la Linerva. We know what's in /etc/sudoers, so we can do this. |
|||
