My Weblog

For those of you who don't use the folder /data/christina, you can ignore the rest of this message.



I had an oops with the permissions on christina yesterday that forced me to take it offline. It is now online again and /data/christina is available.

However, I had to change the SSH key, so you will dire receive warning messages when you try to ssh to christina. To access christina, you will have to delete all lines referring to christina or christina.astro.yale.edu from your ~/.ssh/known_hosts file in your home directory.



Regards,

Hi Everybody,

I would like to request that anybody who has received a copy of my computer survey and not filled it out, to return it next week. If you did not get a copy and would like one, please contact me.

Your survey responses will be help in adopting computer policies for purchasing new computers, file storage, network upgrades, etc. As well, we will use survey results as part of our case when we go to the university looking for more computer resources.

Thanks,

I made a minor change to the startup script for iraf (/usr/bin/local/cl, /usr/local/bin/ncl).

I added an entry to set the memory "stacksize" in Linux. This may help for people receiving memory corruption errors while using iraf on machines using Scientific Linux, Suse or RedHat Enterprise.

Please contact me if you have any iraf problems, or if you have any questions.

----------------------

Below is the relevant information from the iraf v2.12.2-Export release notes:

2.1 Special Note to Fedora and RHEL Users

Preliminary testing under Redhat Fedora and Enterprise Linux systems has revealed a potential problem with the interaction between the MEMIO interface and user resource settings. We do not yet know whether this will affect other distributions using the same newer glibc and kernel versions, or if this is a problem peculiar to Redhat. In either case the workaround will be similar and the problem will be addressed more fully in the next release. Specifically, pointers allocated in the normal course of a task may occassionally be at an address outside the user's per-process stack space, resulting in a "memory has been corrupted" or "segmentation violation" error. This problem was seen during the beta test period with IMFORT tasks and was originally thought to be a problem with the "exec-shield" feature of Fedora, but has also appeared on RHEL systems without exec-shield.

The workaround is to remove the stacksize limit in the user's shell with a command such as

limit stacksize unlimited # for tcsh users ulimit -s unlimited # for bash users

As a preventive measure against this problem, the CL startup script was modified to implement this change and so most users who only use IRAF from the CL will not need to take any special action. This remains an issue for IMFORT tasks however, and users may need to use one of the above commands to get the tasks to run correctly.

-----------------------

i everyone,

We had two issues over the past 24 hours that caused to network to crash.

The first was problems related to heavy activity ("too many files open") on one of the file servers, roc. This started around 9:30pm Monday night and continued until 10am Tuesday when Kwang-Ho rebooted the machine.

The second problem occurred aroudn 2:00 pm on tuesday. Again, the file server froze, halting most of the computers connected at that time.

I am not sure what caused this second incident. I made some changes to correct for problem #1, which may have caused something else to break...

Anyways, no data was harmed during this incident, and I don't think any permanent damage was done.

We had another freeze in our network about fifteen minutes ago. I rebooted the file server again. It appears the problems from earlier this morning may not be resolved. I will keep everyone posted. --Chris

We had some unexpected problems with logins and accessing /home folders this morning. We rebooted roc, one of our file servers around 9:30am this morning. This cleared up the problem which was caused by "Too many files open", i.e. the server was heavily loaded.

Most computers seem to have recovered without intervention. If you continue to have problems, I recommend you logout and reboot your workstation.

Hi everybody,

Over the last two weeks, we have had problems with the security settings for the wireless network being disabled. The result is that all laptops that are "registered" to access our wireless network no longer can. Each time I have to re-enable the security, but usually the next day it has been disabled again. This has particularly been a problem for the graduate student offices.

I do not think this is happening intentionally, it may a particular program behaving erratically unknown to its owner. I would like to remind everyone to please speak with Kwang-Ho or myself, or astro.support@yale.edu if you are having problems with wireless networking.

The basic syntax is: nb [-b blog_dir] [options]

How to ...

• create new weblog (directory) = nb -b [blog_dir] -a
• create new entry = nb -a
• create new category = nb -c new -a
• create new entry with category = nb -c [cat_id] -a
• list entries = nb -l [all|DATE|max]
• list categories = nb -l cat
• list entries by category = nb -c [cat_id] -l [all|DATE|max]
• edit entry = nb -e [entry_id]
• move entry to category = nb -c [cat_id] -m [entry_id]
• delete entry = nb -d [entry_id]
• delete category = nb -c [cat_id] -d cat
• delete entry from category = nb -c [cat_id] -d [entry_id]
• draft entry = nb -E [draft_file]
• import draft as entry = nb -f [draft_file] -a
• force update of weblog files = nb -u [all|DATE|main]

Thank you for trying NanoBlogger. Please direct comments and suggestions to the mailing list or submit a bug report to the project page on sourceforge.net.

Dear Astro folks,

Starting next week, I generally won't be available in the mornings to help with computer problems.

However, Kwang-Ho has agreed to help out during this time. He will keep office hours Monday thru Thursday from 9:30am to 12pm. His office is room 207 in JW Gibbs. Craig Henry is usually also around the department in the mornings. As always, you should email astro.support@yale.edu regardless of who you talk with :)