MIRC6:2011OSUpgradeChat
Use this page to update our running list of questions and problems with upgrading MIRC from gentoo/rtai to debian/xenomai.
Please use your initials to write questions and when they are responded to. we should move answered questions to the top.
JDM: Why is new mirc crashing when reading large arrays?
XC: There are two initializations of two pointers in the code, and if I comment them out, the code seems to run smoothly. I have paste the two initializations here:
1. bzero(bkgndBuffer,daq.rows*daq.cols*daq.nreads*daq.numberOfFrames*sizeof(float) );
2.
for (n1=0;n1<daq.cols/2; n1++) {
for(k2=0; k2< daq.rows/2; k2++){
lf = (exc.lambda-(exc.bandwidth/2.0)) + exc.bandwidth*k2/(daq.rows/2-1);
lf = exc.lambda/lf;
for (k1=0;k1<daq.cols/2; k1++) {
*(xtransform+k1+k2*daq.cols/2+n1*(daq.cols/2*daq.rows/2)) =
(float complex) (lf*cos(2*PI*lf*k1*n1/(daq.cols/2))) +
I*(float complex)(lf*sin(2*PI*lf*k1*n1/(daq.cols/2)));
*(xtransform_re+k1+k2*daq.cols/2+n1*(daq.cols/2*daq.rows/2)) =
(float) (lf*cos(2*PI*lf*k1*n1/(daq.cols/2)));
*(xtransform_im+k1+k2*daq.cols/2+n1*(daq.cols/2*daq.rows/2)) =
(float)(lf*sin(2*PI*lf*k1*n1/(daq.cols/2)));
}}}
for (n2=0;n2<daq.rows/2; n2++){
for (k2=0; k2< daq.rows/2; k2++){
*(ytransform+k2+n2*daq.rows/2)=
(float complex) (cos(2*PI*k2*n2/(daq.rows/2))) +
I*(float complex)(sin(2*PI*k2*n2/(daq.rows/2)));
*(ytransform_re+k2+n2*daq.rows/2)=
(float) (cos(2*PI*k2*n2/(daq.rows/2)));
*(ytransform_im+k2+n2*daq.rows/2)=
(float)(sin(2*PI*k2*n2/(daq.rows/2)));
}}
JDM: presumably the next step is to find where the memory for these variables is allocated and to make sure there was enough space allocated!
JDM: Assuming we can compile code in our own home accounts, how do we actually execute RTScheduler and spooler with the correct permissions/authority? use sudo? login as root?
EP: I just reminded myself... The CHARA lib and header are in /usr/local, MIRC binaries are installed in /usr/local/bin when you type make install. You just checkout control/MIRC, cd control/MIRC and make. I just tried and it works
To execute you could do this: open a terminal, login as root and execute RTscheduler (if it is installed in /usr/local/bin or ./RTScheduler (60000 may be redundant).
JDM:two problems with this: 1) login as root!? this does not sound like an improvement for security when observers are using mirc. 2) we often want to run our OWN experimental version not the installed version . how do we do this without logging in as root? it sounds like Xiao has figured out how to do with sudo, so maybe that is our best option.
EP: I thought you did not like sudo and wanted a root account. Debian does not use sudo by default but rather su. There is a remote possibility that changing debian from su to sudo authentication may break something, probably the package manager gui (which we do not use anyway). If we use sudo we should disable the root login. This does not mean that root is disabled but rather that you cannot login with a root password. To access the root account you type "sudo su -" and type your password.The advantage is that an attacher cannot try to guess the root password (because passwd login is disabled) but rather find out who has sudo privileges and guess the password. This is the old Mirkwood sudoers file (use visudo to edit. If you screw up you will not able to login any more)
# sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # See the sudoers man page for the details on how to write a sudoers file. #
# Host alias specification
# User alias specification
Cmnd_Alias SPOOL = /usr/local/bin/spooler, /bin/su spooler - Cmnd_Alias ASTRO = /usr/local/bin/astropci_usr,/bin/mount /mnt/cdrom,/bin/umount /mnt/cdrom,/bin/mount /backup,/bin/umount /backup,/sbin/reboot,/sbin/halt
- Cmnd alias specification
- Defaults specification
- Reset environment by default
Defaults env_reset
- Uncomment to allow people in group wheel to export variables
- Defaults:%wheel !env_reset
- Allow people in group users to export specific variables
- Defaults:%users env_keep=TZ
Defaults:iluvatar !env_reset
- Runas alias specification
- *** REMEMBER ***************************************************
- * GIVING SUDO ACCESS TO USERS ALLOWS THEM TO RUN THE SPECIFIED *
- * COMMANDS WITH ELEVATED PRIVILEGES. *
- * *
- * ONLY PERMIT SUDO ACCESS SPARINGLY, AND NEVER ALLOW ACCESS TO *
- * UNTRUSTED USERS. *
- ****************************************************************
- User privilege specification
root ALL=(ALL) ALL iluvatar ALL=(ALL) ALL
- Uncomment to allow people in group wheel to run all commands
- %wheel ALL=(ALL) ALL
- Same thing without a password
- %wheel ALL=(ALL) NOPASSWD: ALL
- Samples
- users ALL=NOPASSWD:/bin/mount,/mnt/cdrom,/bin/umount,/mnt/cdrom,/bin/mount,/data,/bin/umount /data
mircdev ALL = NOPASSWD: /usr/bin/make astropci_install,/home/mircdev/control/astropci-rtai/user/astropci_usr observer ALL = (spooler,root) NOPASSWD:SPOOL, NOPASSWD: ASTRO
- %users localhost=/sbin/shutdown -h now
As you can see towards the end you can configure root privilege for specific users and for specific commands.
For the spooler login as spooler and type spooler (or ,/spooler from your directory)
JDM: so who can compile and install new libraries in /usr/local? what is the process?
EP: anyone can compile the binaries or libraries in his on directory. Only root can install in /usr/local (or administrator with sudo)
The process?
make
make install
The CHARA libs are more finicky. I just checked out the essential libs. Theo told me to checkout and compile everything, but that is HUGE and half of it does not compile. I just checked out and compiled the minimum necessary.
The other possibility would be to mount the CHARA libs from michelson on /usr/local or somewhere else. This could be done using sshfs instead of NFS.The advantage would be that when Theo changes something in the libs it will be immediately available to us. The disadvantage is that when Theo changes something it will probably break our system.
