Re: [Ldsoss] PHP remote development environment
On Wednesday 25 April 2007 07:15:19 Thomas Haws wrote: vi, Zend, XAMPP, nano, and rsync--Yikes! I really need to do this right. I'm going to think about all this and bring up some follow-up questions later. Thanks. Tom One thing I really find helpful working remotely is Xnest. If you setup your XDMCP to respond to remote X terminals it is very handy to connect remotely via ssh and run the command Xnest :30 -query 127.0.0.1 Xnest lets you run the full gnome/kde/ice/X desktop remotely. ssh keeps the datastream encrypted so the traffic is secure. If you don't know how to setup your X let me know. I'll setup a step by step instructions and post them. Working remotely can be almost the same as working local. good luck oscar ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
[Ldsoss] dynamic html patent
There is a new article about a lawsuit over the use of dynamic html Is anyone aware of a patent on dynamic html? the article: http://www.groklaw.net/article.php?story=20061122103657390 basically - if I release an application which uses dynamic html am I (and anyone using the code) now open for a patient infringement lawsuit? If the development and use of dynamic html is patented in the US should I just drop html and rewrite the code to be non-html (qt, gtk, ?)? thanks oscar ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - security
After reviewing the urls (the ones that are valid) I did not see anything to suggest php is any worse or better than any other language. My number one choice would be to use c. The app should support winxx, mac, unix, linux and text (if possible). The app also must scale from localhost to intranet to internet. The app must also scale from a few users up to several hundred or more concurrent users. Security of data is more important than speed or user ease of use. The app should also require the minimum software installs on the user's machine and add no additional security risks for the users. As I have reviewed the various requirements and options basing app on the web is the best option I see. Feel free to make your suggestions. My Langauges - c, c++, bash, perl, php, assembler, fortran, pascal, cobal. I gave up trying to learn java - I just do not have that much time to spend. Python - it is a great language but counting columns is something I don't do anymore - too much fortran, assembler, and cobol. Maybe next time. That leaves php or perl unless someone knows some really cool c and c++ tricks. That still leaves the problem of how to secure the app and make some of the user information persistant - no one wants to enter their userid and password on every form. Cookies and hidden data fields seem to be the only real option. What are the other options? I have considered having one user enter the data and a second confirm the data. Right now cookies still look like the best option. thanks for the help and comments oscar On Saturday 19 August 2006 11:20 am, Steven H. McCown wrote: I'm resending this since it bounced. Something about being over 40KB. There are some more serious security implications with your choice of tools (e.g., injections). Far from the definitive word, these are hotly debated, demonstrated, and refuted. Here are a couple of blog articles that you should research and consider re PHP: - PHP Insecurity: Failure of Leadership (http://www.greebo.net/?p=320) - PHP Security: Dumb Users or Dumb APIs? (http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb- a pis/) This is from last year's Blackhat, but it's fairly new and still relevant: - Beefed up OWASP 2.0 introduced at BlackHat (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci111 1 443,00.html) and (http://www.owasp.org/index.php/Main_Page) How to harden this? It's a moving target. PHP6? Until it is released and then I'll say PHP7. ;-) The key is that if you don't *really* have to be web-accessible, then don't. Steve ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Tuesday 15 August 2006 8:24 pm, A. Rick Anderson wrote: Oscar Schultz wrote: On Monday 10 July 2006 10:04 am, Tom Welch wrote: Good start Oscar. It is a start. I'll add the changes, modify into sql and repost. Did you ever get the table definitions done as SQL? Hello list, Between scout camp, yw camp and family reunions I done some but not as much as I wanted to the tracker. Below is what I currently have The question for the list is how to make the user interface secure. The tools I have selected are mysql, php5, pear, apache2, and linux as the base os. The application will run as a web server (server side code rather than _javascript_) and will require cookies. I have been reading about cross-side script attacks (xss). xss looks to be a serious problem since it uses man in the middle to steal cookies. Anyone have some ideas how to harden a web application so I can avoid design problems upfront. thanks oscar create database tracker; grant create,alter,select,insert,update,delete on tracker.* to [EMAIL PROTECTED] use tracker; #the table to record personal information create table people ( record_id int(32) unsigned auto_increment, firstname varchar (30) not null default '', middlename varchar (30) not null default '', lastname varchar (30) not null default '', preferredname varchar (30) not null default '', gender varchar (1), birthdate varchar (2), birthmonth varchar (3), birthyear varchar (4), emergency_passphrase varchar (30), date ); # the table to record personal address information # 1 people record to many address record relationship create table address ( record_id int(32) unsigned auto_increment, people_record_id int(32) unsigned auto_increment, address1 varchar (40), address2 varchar (40), city varchar (40), county varchar (40), state varchar (40), zipcode varchar (9), type varchar (10), # (primary, secondary, mailbox, residence, shipping, other, unknown) date ? ); # the table to record personal phone information # 1 people record to many phone record relationship create table phone ( record_id int (32) unsigned auto_increment, people_record_id int(32) unsigned auto_increment, type varchar (10), # (personal cell, home, business, home2, business cell) area_code varchar (3), number varchar (7), extension varchar (7). date ?. ); # a table to record emergency contacts # 1 personal to many personal relationship create table emergency_contact record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned, #(participate) people_record_id int (32) unsigned, #(emergency contact) relationship varchar (32), # string date ? ); # the authorization table to control access via the # web interface create table auth ( record_id int (32) unsigned auto_increment, fname, #first_name mname, #middle_name lname, #last_name userid, password, password2, auth_level, email, password_start_date, password_status, date ? ); # a table to record the high level in the hierarchy # of the award requirement, subrequirement chain create table awards ( record_id int (32) unsigned auto_increment, name varchar (128), #the name of the award org_group int (32) unsigned, # link to the group record max_age int (2) unsigned,# max age the award can be obtained min_age int (2) unsigned,# minimum age for award date ? ); # a table to record each completed award # many awards to 1 people relationship create table completed_awards ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, award_record_id int (32) unsigned auto_increment, date_completed varchar (9), #ddmmm ); # a table to record which image file relates to which person # each file is a scanned image of the medical form create table medical_form ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, image_record_id int (32) unsigned auto_increment, date ? ); # a table to record which image file related to which person # and event Each image is a scan of the completed doc # many permissions to 1 person relationship create table permission_form ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, event_record_id int (32) unsigned auto_increment, image_record_id int (32) unsigned auto_increment, date ? ); # a table to relate people to pictures # many to many relationship create table picture_people ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, picture_record_id int (32) unsigned auto_increment ); # a table to record each picture and metadata
Re: [Ldsoss] Scout Tracking
add the changes, modify into sql and repost. thanks oscar Tom Oscar Schultz wrote: Hopefully someone on the list has reviewed my set of tables and fields. no responses about the structure yet. I need a list of the needed basic functions to produce a tracker with a minimum set of functions . A set of functions to manage (add,delete, modify) people, events, awards, requirements, and produce a set of reports is what I think are needed . Additionally a set of functions to manage access to the program data. Any linux fans out there have a favorite tool to design the application. I'm looking for a good tool to flow-chart with and to do the initial design work of the app. I have looked at using umbrello to doc/flowchart the app . Suggestions are appreciated . I also plan to use sane and subversion, to extend what I can write to include scanning and image/picture version tracking . thanks oscar On Friday 07 July 2006 10:44 pm, Oscar Schultz wrote: I have spent some time attempting to setup a sql database and tables as the basis for my version of the tracking software. Hopefully those database admins out there can review my table outline for missing fields and/or crazy table relationships and make some helpful comments. enjoy and thanks oscar #the table to record personal information people_table record_id firstname middlename lastname preferredname gender birthdate birthmonth birthyear date # the table to record personal address information # 1 people record to many address record relationship address_table record_id people_record_id address1 address2 city county state zipcode type (primary, secondary, mailbox, residence, shipping, other, unknown) date # the table to record personal phone information # 1 people record to many phone record relationship phone_table record_id people_record_id type (personal cell, home, business, home2, business cell) number date # a table to record emergency contacts # 1 personal to many personal relationship emergency_contact_table record_id people_record_id (participate) people_record_id (emergency contact) relationship date # the authorization table to control access via the # web interface authorization_table record_id first_name middle_name last_name userid password password2 auth_level email password_start_date password_status date # a table to record the high level in the hierarchy # of the award requirement, subrequirement chain award_table record_id name type (LDS,BSA,other) level (youth(deacon,teacher,priest,scout,cub,varsity,venture,adult) max_age min_age date # a table to record each completed award # many awards to 1 people relationship completed_awards_table record_id people_record_id award_record_id date_completed # a table to record which image file relates to which person # each file is a scanned image of the medical form medical_form_table record_id people_record_id image_record_id date # a table to record which image file related to which person # and event Each image is a scan of the completed doc # many permissions to 1 person relationship permission_form_table record_id people_record_id event_record_id image_record_id date # a table to relate people to pictures # many to many relationship picture_people_table record_id people_record_id picture_record_id # a table to record each picture and metadata about the picture picture_table record_id date_of_picture location description filename # a table to record each scanned image/doc # 1 people to many images relationship image_table record_id filename image_date description image_owner_people_record_id # a table to record event information for calandaring event_table record_id event_start_date event_end_date description group (miamaids, bears, scout, priest etc) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Hopefully someone on the list has reviewed my set of tables and fields. no responses about the structure yet. I need a list of the needed basic functions to produce a tracker with a minimum set of functions . A set of functions to manage (add,delete, modify) people, events, awards, requirements, and produce a set of reports is what I think are needed . Additionally a set of functions to manage access to the program data. Any linux fans out there have a favorite tool to design the application. I'm looking for a good tool to flow-chart with and to do the initial design work of the app. I have looked at using umbrello to doc/flowchart the app . Suggestions are appreciated . I also plan to use sane and subversion, to extend what I can write to include scanning and image/picture version tracking . thanks oscar On Friday 07 July 2006 10:44 pm, Oscar Schultz wrote: I have spent some time attempting to setup a sql database and tables as the basis for my version of the tracking software. Hopefully those database admins out there can review my table outline for missing fields and/or crazy table relationships and make some helpful comments. enjoy and thanks oscar #the table to record personal information people_table record_id firstname middlename lastname preferredname gender birthdate birthmonth birthyear date # the table to record personal address information # 1 people record to many address record relationship address_table record_id people_record_id address1 address2 city county state zipcode type (primary, secondary, mailbox, residence, shipping, other, unknown) date # the table to record personal phone information # 1 people record to many phone record relationship phone_table record_id people_record_id type (personal cell, home, business, home2, business cell) number date # a table to record emergency contacts # 1 personal to many personal relationship emergency_contact_table record_id people_record_id (participate) people_record_id (emergency contact) relationship date # the authorization table to control access via the # web interface authorization_table record_id first_name middle_name last_name userid password password2 auth_level email password_start_date password_status date # a table to record the high level in the hierarchy # of the award requirement, subrequirement chain award_table record_id name type (LDS,BSA,other) level (youth(deacon,teacher,priest,scout,cub,varsity,venture,adult) max_age min_age date # a table to record each completed award # many awards to 1 people relationship completed_awards_table record_id people_record_id award_record_id date_completed # a table to record which image file relates to which person # each file is a scanned image of the medical form medical_form_table record_id people_record_id image_record_id date # a table to record which image file related to which person # and event Each image is a scan of the completed doc # many permissions to 1 person relationship permission_form_table record_id people_record_id event_record_id image_record_id date # a table to relate people to pictures # many to many relationship picture_people_table record_id people_record_id picture_record_id # a table to record each picture and metadata about the picture picture_table record_id date_of_picture location description filename # a table to record each scanned image/doc # 1 people to many images relationship image_table record_id filename image_date description image_owner_people_record_id # a table to record event information for calandaring event_table record_id event_start_date event_end_date description group (miamaids, bears, scout, priest etc) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
True - storing data/forms is challenging. Tracking awards makes planning and program management easier. Access to information however is required for trips. The required documentation for an outing to occur is: a permission slip per person, a required medical form (normally a class 2) per person, a valid trip permit, and the safe scouting guide. If the group is split into multiple vehicles/groups each adult group leader should have a copy. To prevent document loss normally copies at home are recommended for the duration of the trip as well. Just imagine getting to a hospital for help and having to wait for paperwork because it is in the lake/river with your canoe or back in the busted vehicle . Worst case docs from home can be faxed in minutes. When each leader has a copy - no problem except for collecting the doc at the each of each trip. When an emergency occurs the activity/trip leader needs access to forms normally on paper. Having good documentation is fundamental to success. Having good documentation for awards is also required - it make it a lot easier to plan a program and to keep everyone on target. What is needed is how to organize the data to protect the data, methods to limit access, and how to track access to the data. I plan to use linux, apache, mysql, and php. There are controls at each level - so how to lock down access at each level ? oscar On Friday 07 July 2006 7:21 am, Slide wrote: On 7/6/06, Oscar Schultz [EMAIL PROTECTED] wrote: snip mine first_name middle_name last_name preferred_name gender birth_day birth_month birth_year record_id date_recorded It will all go into a sql table Address, phone, email will be separate tables since people can have multiple of each. My plan is to use either MySQL or PostGRES, php, apache, and linux with a web interface. My list of tables: people, addresses, phones, emails, events, attendance, awards, requirements, images, pictures, completed_awards, completed_requirements, emergency_contacts, medical_forms, and permission_slips should be interesting Be careful with some of this information; are you planning on storing medical information or just a flag saying they have turned in the medical form? Storing medical information would probably be a bad idea. slide ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
[Ldsoss] Scout Tracking
I have spent some time attempting to setup a sql database and tables as the basis for my version of the tracking software. Hopefully those database admins out there can review my table outline for missing fields and/or crazy table relationships and make some helpful comments. enjoy and thanks oscar #the table to record personal information people_table record_id firstname middlename lastname preferredname gender birthdate birthmonth birthyear date # the table to record personal address information # 1 people record to many address record relationship address_table record_id people_record_id address1 address2 city county state zipcode type (primary, secondary, mailbox, residence, shipping, other, unknown) date # the table to record personal phone information # 1 people record to many phone record relationship phone_table record_id people_record_id type (personal cell, home, business, home2, business cell) number date # a table to record emergency contacts # 1 personal to many personal relationship emergency_contact_table record_id people_record_id (participate) people_record_id (emergency contact) relationship date # the authorization table to control access via the # web interface authorization_table record_id first_name middle_name last_name userid password password2 auth_level email password_start_date password_status date # a table to record the high level in the hierarchy # of the award requirement, subrequirement chain award_table record_id name type (LDS,BSA,other) level (youth(deacon,teacher,priest,scout,cub,varsity,venture,adult) max_age min_age date # a table to record each completed award # many awards to 1 people relationship completed_awards_table record_id people_record_id award_record_id date_completed # a table to record which image file relates to which person # each file is a scanned image of the medical form medical_form_table record_id people_record_id image_record_id date # a table to record which image file related to which person # and event Each image is a scan of the completed doc # many permissions to 1 person relationship permission_form_table record_id people_record_id event_record_id image_record_id date # a table to relate people to pictures # many to many relationship picture_people_table record_id people_record_id picture_record_id # a table to record each picture and metadata about the picture picture_table record_id date_of_picture location description filename # a table to record each scanned image/doc # 1 people to many images relationship image_table record_id filename image_date description image_owner_people_record_id # a table to record event information for calandaring event_table record_id event_start_date event_end_date description group (miamaids, bears, scout, priest etc) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Since you already put in a lot of time and effort you should better know where the problems are in a web based system. Outlining the problems would save anyone just starting a lot of time and false starts. . Please outline what requirements you believe a tracking program should satisfy and what features you believe are needed (perhaps level 1,2 and 3 level requirements/features). Please outline the security/protection requirements (rather than implementation methods) you found. thanks oscar On Sunday 25 June 2006 1:44 am, Robert Nickel wrote: Although this message is not in reply to a specific message, I'm going to reference many of the items spoken by folks. Having put some serious thought and energy into development of a web based troop tracking system, I have been following this thread with a great deal of interest. This has helped me to gel some of the concerns and ideas that I've had in the past together. First; if someone is to sponsor a central database, we should *not* look to the church for a scouting oriented database. We should offer our efforts to BSA. This way, the program could benefit all scouts and not be viewed exclusively as an LDS thing. Second; DTG should become part of MIS, or at the very least, be centralized through the clerks office. This way, all of the features that have been touted of the etrailtoeagle program can be realized via the church email system. Third; to alleviate the concerns that have been expressed about the volume of personal information stored in an online database, I would suggest just not allowing for the storage of that information. What is the requirement for tracking all of the things that TroopMaster tracks? Personally, I think TroopMaster suffers from massive feature creep. Things like insurance values, license numbers and parental contact information should either be tracked completely offline or on paper. Although the improved security garnered by this approach is dubious, the fact that we're trying to track progress and not all the ancillary things associated with scouting should serve as a primary focus. I think that the discussion has been healthy but that there are definitely different views of what the scope of the project is going to be. Without some definition of this scope, the discussion to date can have *very* different meanings for each person on the list. I think that Tom [0] should set down some initial criterion for the project before anyone decides to spin off yet another scout tracking system (YASTS). --Robert [0] It appears that Tom was the originator of the thread from the link that I was given. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Calendar Import
I've added items to the Ward Calender several times. The interface works. If you need to enter many items it is a problem - the same problem with other calender interfaces. Having a direct access to the database simply bypasses the review/approval process - It would not really reduce the effort required to keep the information up to date. The easiest way I know to reduce the effort required to keep a Ward/Stake calender up to date is to get many people involved. I ask the Sectartaries and Presidencies in each auxiliary/organization to input the calender events and details. Since anyone in a Ward can enter an event the Ward webmaster only need to review and approve or reject the entries. If you can get others to help and support the webmaster the calling can be fun rather than a burden. The president/counselors/secretary should all the information needed to enter an event - let them enter the information - that way there are fewer mistakes, more folks have an interest in keeping the calender current and more folks will use it. oscar On Friday 21 April 2006 10:25 am, Bill Pringle wrote: I attended a Stake training meeting for web site administrators, and the common complaint was how difficult it was to enter information. One of the biggest complaints was how long it takes to enter calendar information. Way back when these web sites went on-line, I suggested the need to import calendar information. I was told it was a good idea, and they would look at it, but nothing has happened since then. Does anyone know if there is any actual effort underway to make entering information on the web site easier? --- Bill Pringle work: [EMAIL PROTECTED] http://www.unisysfsp.com http://www.unisys.com home/school: [EMAIL PROTECTED] http://www.personal.psu.edu/~wrp103 http://CherylWheeler.com ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Removing balance forward / Balance
You should contact a member of your Stake Finance Committee, the Stake Clerk and you Bishop for one on one help. There are a very limited number of people to whom this information should be exposed to and it should always be done privately. If you are one of the Stake people contact Church Headquarters. The other account should normally be zero (0). If someone has had a check returned for insufficient funds the ward other account will get the credit and you have to contact Church Headquarters for instructions. You can not modify or correct the balance on your own. The only method to correct the balances is to work with Church Headquarters. The folks there are very kind, patient and helpful - They have been a great help to me in the past. They will work with you throughout the process to correct the balances. Good luck. It is a bit daunting the first time but with some help the process is pretty interesting. oscar On Monday 20 February 2006 10:22 am, Chris Petersen wrote: How do I zero out the Balance Forward / Balance amounts. The following report has balance forward. Income and Expense Summary by Sub-Category (01 Jan 2006 -19 Feb 2006). It would also be helpful to know more about this purpose of this report. Thanks Chris Category Balance Forward Donations ExpensesTransfersBalance Budget: District Primary$35.94--- ------ $35.00 Other -$1,113.04 - -$1,113.04 ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
[Ldsoss] helping the Church by developing. was : MLS Bugs and Discussions
On Saturday 14 January 2006 08:14 pm, Manfred Riem wrote: snip/snip I know that I would like to know how many fellow LDS developers are out there and what we could do to help the Church in any way possible. Wouldn't you? ;) Kind regards, Manfred Riem Just my personal opinion, The Church needs skilled developers, most organizations do. The trouble in using new developers is the effort required to train the developers to do things a particular way. Each developer needs skills in multiple languages, operating systems, source code control, source coding standards, APIs, how to work in a group, and the list goes on and on. The training takes time and someone who understands how to do it correctly will need to teach those skills. The teaching takes time away from creating new or better applications. Setting up to use several new developers can be quite a burden. The best one can do right now is to get active in a community and get some good experience. If you are a C coder join a project that is heavy into to real C code. Do more than just read books and wait for something to happen. Become a skilled world class developer. If you don't have a project then find an itch, start a project and scratch. Hopefully someone in the Church will publish their coding standards and best practices so we can each start to become fully trained and ready for when the opportunities come. It is a lot like preparing for missions. The training for new missionaries today begins years prior to the call. There are new aids and standards in place to help and guide those who are preparing so they are ready when their time comes. Training for those 19 year old missionaries (and others) just entering the MTCs began 19+ years ago. Now is the time to prepare. Example - If you don't like the way MLS is today write your own, GPL the code and submit the code for review to the Church. Spend enough time to build a solid foundation and document it very very well OR build a program to assist people to become prepared - build a recipe program (ERP and Inventory control) to build a 1 year supply as an extensions of their everyday meal and money planning. Be sure to conserve users resources, increase the abilities of those preparing meals, meet nutritional needs, and do it with a minimal impact to the user. Do not forget some folks have food allergies ! Of course make the interface easy to use and maintainable. Perhaps a plugin to GNUCash would be a good place to help. When the time comes to help fix MLS you will be ready to share code and your new knowledge and code will not go to waste. I prefer Web interfaces, MySQL, PHP, and linux. Building a solid web program that is secure, fast, small, and supports multiple languages is hard work. Getting the experience to do it quickly takes time and effort. My current project is one to scan paper docs and index the docs for quick retrieval. Building it has been fun but very challenging. After a few hundred hours coding and many hundreds of hours researching how the various interfaces work things are finally starting to work. I still have a long way to go and much to learn. The project is now in use and starting to help a friend with a paper problem. We are working on version 0.4.0. Hopefully 0.4.0 will be ready to release in the next few weeks. PHP, SQL, WWW and others are (finally) becoming friends. Next is learning to tame CVS, rpm/apt/emerge/make, a project editor and version 0.4.1 ! Then on to 0.4.2 . It has been great fun. May God bless your endeavors oscar snip ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Emergency Preparedness Software
On Friday 13 January 2006 09:19 am, Mac Newbold wrote: Today at 12:01am, Oscar Schultz said: I'm more interested in the communications part of EP. Most plans I see setup a structure around ham radio ops and voice or cw traffic as done snip /snip The Church is the force pushing ham radio for emergency communication. There is a calling at the stake (and in some cases, ward) level for Emergency Communications Specialist. Their calling is to be a ham radio operator (or work closely with one) to coordinate communication between the stake and the Church (via the local Welfare Region, generally) in an emergency. The Church has numerous resources in place to facilitate such emergency communication, and there's a weekly on-the-air training meeting, in the Salt Lake area at least, for people serving this way. The church has radio equipment and operators ready, including repeaters with emergency power, so that they can maintain effective communication in a disaster. True -in my area it is mostly central station flow controlled voice traffic - very low volume - it works but most of the time bandwidth is wasted in overhead - that's the way voice traffic works. The guideline on privacy that I heard last time I talked with them (about a year ago, more or less) was that no names or identifying information was to be passed on the air. They said that primarily it would be a matter of identifying the stake for which you were reporting, and giving information about the current situation and needs and what assistance you may be able to provide to others. All information about people (members or not) would be in the form of numbers only - counts of people, totals, and never names or other personally identifying information. It is too easy to disregard the guideline while trying to do the right thing. The non life-threatening traffic really should be carryed on a RTTY type net just to conserve the bandwidth on the voice net. Converting to digital allows filtering and other content control methods. Regarding cell phones, snip /snip http://www.arrl.org/FandES/field/regulations/news/part97/ see part 97.113.a.5 - once cell phones or FRS or any other radio service becomes available the amateur station is to basically close down. What would interest me would be to setup a station(s) and apps to pass traffic that is very difficult to pass using current methods - basically email, pictures, video, various HTML forms (building inspections, work party schedules, material orders (where do you need a tarp and what size)) - all the stuff needed to stabilize/rebuild a region. The bulk of the data is third party and contains too much volume to pass in a voice network. What I see is many NAT'ed local networks (10BaseT?) with multiple nodes. Perhaps 1 per Ward or building (or even 1 per work team - laptop with radio). Each NAT server would connect to the outside world (next up center) via a radio link (2 meter, 440, cw, software radios, ???). The idea is much like how my home network (10 nodes) is connected to the internet via a diald link. With the correct apps the local net could provide level 1 coordination and act as a cache to outside services to coordinate the outflow of area needs and information. A HT/VTer could report simply by selecting a simple html form from a web server on the local server, fill it in and submit it. An Apache script (php?) could process the form data and coordinate emergency/high priority needs. The entire system minus the radio links could be tested and training done almost anytime just be using standard links like modems, lans or wifis. I would love to see a 2 meter or 3 band radio I could connect to a computer via usb or ethernet tcpip. The big ? is how to setup the links using plain jane radios or whatever you have or can get. Software radios look very interesting. If one could just get even 36kbaud down a 2 meter link how different things would be. 300 and 1200 baud is a bit limiting. oscar ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Emergency Preparedness Software
I'd like to gently remind folks that all the data in MLS is confidential. Exporting data out does not reduce the requirement to protect the data. Each report contains the notice For Church use only. For the time being I suggest sitting down and reviewing MLS's other talents. The use of special categories and geographic zones is made for extended classifications. Our Ward/Stake was able to setup MIS to contain the data for EP 10 years ago. The functions needed are contained in MLS. Admin overhead is reduced using MLS because as members move in or out their records are automagically added and removed. The hard part is keeping up on entering the data of talent and resource from surveys. Also remember information about who has what property/resources, talents/interests is VERY private to many (most) people. For people of other faiths you can add them to the local MLS database. Simply add them and answer N (non-member) in the membership status field. Keeping record of who has a truck is great - if the truck still runs and can be used. Keeping the data up to date is enough to keep 2 membership clerks very busy. The Sec. in the RS, Elders, HPs can be a great asset since they can be used to update the HT/VT info each month. I'd suggest asking for a talent/resource survey to be filled out each quarter from each adult and young adult member. Then updating MLS at least quarterly. Again - All data should be considered confidential. Anyone receiving any data should receive clear instructions to correctly destroy (paper shred, disk wipe, etc) the data once it is not needed. Also instructions should be given to protect the confidentiality of the data. If someone does not need the data they should not have access to it. Printing a quarterly list (folder) of resources is about the only way to make the info available when there is no power. I'm more interested in the communications part of EP. Most plans I see setup a structure around ham radio ops and voice or cw traffic as done from the 30's through the 40's, 50's and into today. Ham traffic can not be secured to encrypt the data as required by some of the new privacy laws. As I read the regs I can not see any legal way to pass traffic which may reveal information about the heath or status of anyone especially a minor. Also if a cell phone is available you may not be able to legally pass traffic of any meaningful nature via a ham radio (even if the cell phone only works some). How are various folks/groups dealing with the requirements to protect personal information? What do folks understand the FCC regs of data traffic on Ham versus cell phones to include? Good luck Oscar On Wednesday 11 January 2006 08:05 pm, Jeff Raymond wrote: One point that has come up in our bishopric meetings is the need to involve nonmember households in our neighborhood preparedness planning. Since our community is mostly LDS, some non-members may feel left out of neighborhood preparedness planning. Perhaps this might be something to consider with respect to information dynamics and who the possible beneficiaries of this software would be. Thanks, Jeff ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] New here.
Sound like you have the situation covered. I've used MIS and MLS data for what seems like forever. Having MIS on a test computer early on when I was learning and crashing the machine over and over (old dos days) was helpful. I have not had a crash in years. That said - Other than training, I really have never really needed (really really needed) MIS or MLS in order to function. Membership data I need - output to a file or paper has worked and continues to work. I've found bandwidth with paper to far exceed the bandwidth I have through a screen (I use computers all day every day). The Bishop/president(s) can work just fine on paper and then have a good secretary to record everything (by entering it in to the computer). I liked having a Palm but as reference only - as a workspace I need a lot more room than a Palm or a CRT can provide. I like working across multiple pages to organize my thoughts and to see the big picture or sometimes just to take notes. Since I only have copies of the reports provided by MLS and not the MLS program I have no conflict about MLS. Guarding the data/reports MLS permits is far easier to deal with and protect than dealing with possible copyright conflicts and the datasync problems etc etc etc. It has just been easier to deal with reports/data than executables, databases, etc. If I were still clerking and the Bishop had a laptop/palm I think the easiest thing for me and him would be for me to borrow his machine for a few minutes and copy a set of reports into a folder for his use. USBsticks are very nice - you can setup multiple folders, they hold a lot of data, they are fast, and fit in a pocket. The setup I would like to see is a linux server supporting thin clients and secure wifi in the building. We often have a waiting line to use the Ward computer. The members have been great working together. The computer is quite central to operations in the Ward. It would really nice to be able to do the financials, update HT/VT districts, update memberships, etc and print phone lists all concurrently. The linux terminal server project with a nice web interface into MLS would be really nice. I'd love to be able to really collaborate in a meeting and have everyone be able to see a central screen and personal with current and proposed changes. Having a terminal in the library with a serious printer (HP4SI, 5si or 8100 etc) or usb port AND a link to lds.org to get talks or other info like genelogy info. Being able to web cam a class into another room or building would be great. A scanner in the library would also be great - then I would not need a photocopier. For teacher development class it would be great to webcam or record the student teacher for later review. Also we have a number of home bound members. I would love to be able to have them be able to attend and participate fully in various classes. A web interface and the ability to send receive video audio would be a huge blessing to those bed bound and home bound members. I doubt now is the time. Still I'd love to see it and help in any way I could. oscar On Sunday 18 September 2005 15:48, Penguin Migration Computer Serices wrote: I just spoke to a member of the Stake Presidency about it today. To sum up, he said that the direction they had been given, was that the information contained in MLs should not leave the building (emphasis is his). However, given our situation (Branch President is 25 minutes away from the chapel in one direction, and I am 20 in the other), putting MLS on the laptop would be fine under one condition, after proper security concerns are looked after. His condition is that there must be no financial information on the laptop. So if I can find a way of zeroing the financial information, or wiping it completely then I have the Stake Presidency's aproval to put MLS on the Branch President's laptop. I'll make sure to double-check before performing the work, but it does need to be decided by someone not within the local leadership. On Sunday 18 September 2005 02:24, you wrote: Richard, Did you receive sufficient counsel ? I would strongly suggest you suggest to your President he contact Salt Lake and the Stake President for counsel AND permission. Without the permission to use the software in that manner both of you are putting both the Church and yourselves in an awkward situation. I have had the same basic request - the counsel I received was the software is not to be used in that manner. Good luck oscar ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
