Recruiting for an open source project Post: 302904950

Sponsored Content

Top Forums UNIX for Advanced & Expert Users Recruiting for an open source project Post 302904950 by steadyonabix on Sunday 8th of June 2014 05:55:36 AM

06-08-2014

Registered User

Recruiting for an open source project

I am posting this gauge the level of interest among the community in forming an open source team to work on an automation harness I am about to make available.

I already have a working POC running at my place of work, but it is not secure enough for production environments. However, I am about to release a more powerful and secure version that is secure enough and offers even more features. I will go into further detail about that later on in this post but in the interest of not wasting anyone's time, here is what I am looking for in the way of people with skills I need:

*) Testers
*) Shell Scripter's (Bash) who can review the code, particularly those with the experience and access to a UNIX environment to make it POSIX compliant. (I am currently developing on Centos). You shouldn't be daunted by the thought of working on a full blown application written in shell either.
*) Project managers with experience in running open source projects.
*) Web masters to put a site together for the project.
*) Code management.
*) Packaging
*) Technical writers for the documentation required.

I would particularly like to hear from anyone with a proven track record in managing an open source project and implementing the processes and procedures required to startup such a venture.

The harness is called MUSE, (Managed Unix Shell Execution) and has the following features:

*) Master - Slave architecture.
*) Plugin code modules.
*) Centralised reporting on master.
*) Automatic report summarisation.
*) Very simple syntax, so shallow learning curve.
*) Agnostic - Will run tools on a distributed cluster of servers that are written in any language, thereby enabling end users to leverage their existing tool sets without refactoring.
*) Event driven, Master and Slave are both implemented as state machines that communicate via a messaging framework.
*) Stateful, current state continuously updated in Sqlite3 databases in master and slave.
*) Secure. Currently implemented via LDAP.
*) Access controlled. Standard NIX user and group mechanisms are used to control who can run what and where.
*) Audited - Everything is recorded internally as well as logged under /var/log/muse.
*) Support for RAD. Feature rich developer tools built in by default but controlled via the access control mechanism mentioned above.

I am currently using the insecure harness to test a Data Warehousing Application in the following areas:

*) Integration testing. Application is distributed across multiple server types.
*) Resilience testing. e.g. Killing processes during data loads, block and unblock ports used by interfaces, consume disc space and memory etc.
*) OAT. Sequencing the upgrade and rollback instructions for operations staff with multiple configurations of distributed servers.

I shall not be releasing the insecure version as it is tightly embedded into my employer's systems and I don't want to waste time anonimising code that I'm not going to release. However the new version is almost ready to share with a team of like minded individuals who would like to be involved in making it generally available.

If you are interested in joining the project then please send me a private message with a potted resume. If I think you are likely to be a help during the early stages of the project, I will ask you for a more formal CV and get in touch with you.

If I think you will be of help later on once the project is set up, I will let you know and keep hold of your details.

Thanks for taking the time to read this.

Brad

steadyonabix

View Public Profile for steadyonabix

Find all posts by steadyonabix

2 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Open source project

Hi Guys, This might not be the right place to ask but I want to contribute to some open source project. Can anyone please help me to how to start and where to start?

2. Shell Programming and Scripting

Feedback on "withsome" open source project

I have been developing an open source UNIX project for a few years and am looking for feedback on whether further development of the "withsome" project is of interest to other programmers. One simple example to give an idea of the project is: withsome ./pugs vi Pugs.pm 1)...

LEARN ABOUT LINUX

openat

OPENAT(2)						     Linux Programmer's Manual							 OPENAT(2)

NAME

       openat - open a file relative to a directory file descriptor

SYNOPSIS

       #include <fcntl.h>

       int openat(int dirfd, const char *pathname, int flags);
       int openat(int dirfd, const char *pathname, int flags, mode_t mode);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       openat():
	   Since glibc 2.10:
	       _XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L
	   Before glibc 2.10:
	       _ATFILE_SOURCE

DESCRIPTION

       The openat() system call operates in exactly the same way as open(2), except for the differences described in this manual page.

       If  the	pathname  given in pathname is relative, then it is interpreted relative to the directory referred to by the file descriptor dirfd
       (rather than relative to the current working directory of the calling process, as is done by open(2) for a relative pathname).

       If pathname is relative and dirfd is the special value AT_FDCWD, then pathname is interpreted relative to the current working directory	of
       the calling process (like open(2)).

       If pathname is absolute, then dirfd is ignored.

RETURN VALUE

       On success, openat() returns a new file descriptor.  On error, -1 is returned and errno is set to indicate the error.

ERRORS

       The same errors that occur for open(2) can also occur for openat().  The following additional errors can occur for openat():

       EBADF  dirfd is not a valid file descriptor.

       ENOTDIR
	      pathname is relative and dirfd is a file descriptor referring to a file other than a directory.

VERSIONS

       openat() was added to Linux in kernel 2.6.16.

CONFORMING TO

       POSIX.1-2008.  A similar system call exists on Solaris.

NOTES

       openat() and other similar system calls suffixed "at" are supported for two reasons.

       First,  openat() allows an application to avoid race conditions that could occur when using open(2) to open files in directories other than
       the current working directory.  These race conditions result from the fact that some component of the directory	prefix	given  to  open(2)
       could  be  changed  in parallel with the call to open(2).  Such races can be avoided by opening a file descriptor for the target directory,
       and then specifying that file descriptor as the dirfd argument of openat().

       Second, openat() allows the implementation of a per-thread "current working directory", via file descriptor(s) maintained by  the  applica-
       tion.  (This functionality can also be obtained by tricks based on the use of /proc/self/fd/dirfd, but less efficiently.)

SEE ALSO

       faccessat(2),  fchmodat(2),  fchownat(2), fstatat(2), futimesat(2), linkat(2), mkdirat(2), mknodat(2), open(2), readlinkat(2), renameat(2),
       symlinkat(2), unlinkat(2), utimensat(2), mkfifoat(3), path_resolution(7)

COLOPHON

       This page is part of release 3.27 of the Linux man-pages project.  A description of the project, and information about reporting bugs,  can
       be found at http://www.kernel.org/doc/man-pages/.

Linux								    2009-12-13								 OPENAT(2)