Re: [OpenIndiana-discuss] More recent modsecurity pkg
On 05/ 3/16 11:25 PM, Stefan Müller-Wilken wrote: Dear all, could anyone with access to the Sun Studio environment do me a great favor and lift the mod_security package from its current IPS incarnation to the 2.9.1 available from modsecurity.org? I tried to compile it with 'gcc' but that will crash Apache httpd under oi_151a9 when loading the module. It is not easy to get older patched Studio releases today. I also tried to install newest Studio on newest OI hipster, but Orcl is making Studio only Solaris-aware and it doesn't regularly install, because of a linker depending on Solaris 11. If anyone of you have support contract with Oracle and wnat Solaris studio to support building on illumos, please ask them via regular channel. Studio that used to be used to compile illumos and OI, before moving to GCC, with md5sums is named: 43ecac9ceecf0dbe8297ae8caacce457 sunstudio12-patched-ii-2009Sep-sol-x86.tar.bz2 1490e3a8eddd972d7467a36afdf88a5a sunstudio12u1-patched-ii-2010Feb-sol-x86.tar.gz (Hash: d08486a68dda65b045b9cd887559fb771da4852c ) Patched SPARC Studio is also not easy to find, (Hash: dde33b1801b8148df06b6980da750c4294f9afdc ) if someone has older,patched Studio for SPARC, please report. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OpenIndiana Docs (proof of concept) - What is it all about?
On 05/ 4/16 04:01 PM, Aurélien Larcher wrote: Michael's initiative is a good way to encourage collaboration since it is based on source files under revision control system, unlike a Wiki. Wiki is much more appropriate space for writing articles like those Michael is writing. People writing articles should not be forced to use github and also Wiki articles are instantly visible on site and could be edited by existing people and there is also space on personal blogs for random articles that could be integrated after re-visioning them. If one wants version controlled docs, it can do that on Openindiana servers instead of reinventing and rewriting everything and moving docs outside Openindiana project and without checking articles from existing people in the project.. Wiki is much better and easier to use and should be used to fine-tune texts before publishing on OI site, so that text on site doesn't jut "appear" one day on site like it is now. Anyone wanting Wiki account, is free to ask on IRC. (having your blog writings or sending article vie e-mail helps). ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OpenIndiana Docs (proof of concept) - What is it all about?
On 05/ 4/16 09:07 AM, the outsider wrote: hipster-hipster version. There's only one OI /hipster , it is published in http://pkg.openindiana.org/hipster (it used to use /hipster-2015 to speed up IPS operations, because of too frequent updates). I am on using OI hipster on both laptop and desktop and I don't miss anything much, thankful to great contributors to OI. Frequent updates? Yes, very vibrant and full of changes, just look at: http://hipster.openindiana.org:8080/ http://hipster.openindiana.org:8080/job/oi-userland/changes and not even all changes form the beginning are displayed.. You can also use SmartOS binaries and packages on Openindiana, , so you can keep Openindiana (hipster) install and have SmartOS binaries too. :) I Bootstrapped SmartOS Pkgsrc (pkgin) and they install in /opt/local and I am reporting bugs to SmartOS folks since they don't have X server by default and I am interested in apps using X. "Option 2: Install software from SmartOS repositories via pkgin", Option 2: http://wiki.openindiana.org/oi/3.+Installing+software+and+package+management In other news, Openindiana hipster always bring newest illumos (illumos it fully tested by multiple companies and has "always stable" policy), so it is easy to spot any changes and new bugs, but also brings newest fixes, and also it brings security patches(!) so even for production that requires fixing bugs, use one can choose OI hipster and for laptops, too of course. To replace Openindiana /dev with new hipster-based /dev , you are asked to test updating from /dev to aether hipster-2015 (that used to be default up to 201604 ISO snapshot or to current /hipster. Missing things are: - 151a8/a9 branded zone that will allow running previously used applications that were compatible with Opensolaris and 151a line, so binaries could continue to function i it's branded zone. (like there is Solaris 10 zone). - updatemanager GUI and packagemanager refresh for current IPS. - Docs covering the transition from /dev to hipster-made /dev. I don't consider that without GUI part that could say "hey I have some updates, would you like to click on me to update" it could be landed on /dev. And for 151a Branded zone, you can guess how much it is important to run old binaries. So please test updating from /dev to aether /hipster-2015 or /hipster ,current one, so that it could be known what to change to be able to replace /dev with hipster snapshot. That kind of landing and releasing from /hipster to /dev could be made possible together with refreshing /dev several times a year (more frequent then ISO snapshots) and could be supported. I am thankful for your response on the list , it is actually RIGHT time to do something about updating /dev and having supported release, but hope you already guess , it needs YOU to activate , test, report bugs and contribute some time into it. :) (Also thanks about docs suggestions) There's almost always someone on IRC, (one can use Xchat/Hexchat and select Freenode as IRC network) so choose your hacking weapon :) : #openindiana - general support contact, general project chat #oi-dev - development questions asks for testing etc #oi-documentation - Docs, advocacy, web site, etc #oi-meeting - place for discussions (like you proposed in this message) Wiki: http://wiki.openindiana.org/oi/Hipster Userland Code patches that OI hipste ris made of: https://github.com/OpenIndiana/oi-userland/ Bug reporting: https://www.illumos.org/projects/openindiana/issues ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [oi-dev] demonstration docs website
On 05/04/2016 06:52 AM, Alexander Pyhalov wrote: > Hi, Michael. > > Thank you for your work. > To move further I think we should consider several questions... > > 1) Someone should look through the docs... So , reviewers are welcome. > Have you changed "OpenSolaris Redistributable Books" in any way or just > created the index and converted them to docbook? How do we mark parts of > the books which are not currently actual? How are we going to update > them (create new document or mark current document as reviewed)? How > http://makruger.github.io/website/pages/docs/handbook.html and > http://wiki.openindiana.org/oi/OpenIndiana+Handbook are related? What > parts are missing? The website is composed of 3 separate components: 1) The Awestruct web framework And the contents of 2 GitHub repositories: 2) https://github.com/makruger/openindiana-docs 3) https://github.com/makruger/docs_20090715 The Awestruct framework works with an Asciidoctor plugin to compile Asciidoc text markup content pages into HTML5 and then deploys it to a gh-pages branch. This branch is published to GitHub pages. The compiler parses through everything it finds and anything which is already compiled (or for which there is no parser) is simply copied over without any further processing. The main index as well as header/footer layouts, etc., are composed in HAML (but can also include snippets of HTML). The 2 GitHub repositories are not configured as submodules, but going forward they probably should be, or alternately things could remain as they are and inclusive of it all. The openindiana-docs repository consists of the FAQ I previously worked on as well as a skeleton for an updated handbook. It also includes several informal 'work products' containing notes and guidance for anyone working on the docs project. Some of these work products could be used in the creation of other documents, others are better reserved for reference use only. As for the handbook, I never envisioned it becoming as comprehensive the OSOL books, but rather be used as a supplement to them. Call it a guide for new users wanting to quickly get up to speed with the operating system. The docs_20090715 repository contains the redistributable books. Here I simply extracted the zipfile (which already contained compiled HTML along with the raw XML sources) and wrote several index pages which linked it all together. These books are as originally released without any further editing. I do not yet have a formal process for updating the books. Up until this point my only concern has been to host them as they are and develop a process for updating them at a later date. > 2) What is the process of contribution, how site is generated? What > tools are used to work on the docs ( asciidoctor + git ?)? At this time the site is manually generated. Though in the future it could be automated using Travis-CI. For those interested in helping with the development of the website itself, Awestruct can be run locally in development mode. This requires a Ruby environment, although this can be simplified in the future by using Gradle. For those who wish to contribute to new or existing content, all that is required is a text editor. I use VIM along with an asciidoc VIM plugin. There is also an Asciidoctor IDE by the name of AsciidocFX. The IDE uses an Atom like text editor along with a live preview of the parsed text. For those who wish to use VIM, there is an Asciidoctor plugin available for firefox (and Chrome as well) which can be used to parse the document and provide a close approximation of it's final rendered form. Content is written using Asciidoc text markup (or more specifically the enhanced Asciidoctor version of it). In either use case (content creation or website development), contributors would fork the repository and submit a pull request to have their changes incorporated. Someone (most likely me or anyone else who wishes to help) would review and merge the changes. As for linking new documents with site menus, this is a manual process, but could be simplified by using TOC pages and adding and simply adding a new line item for the additional document. > 3) How do you propose to incorporate documentation site in current OI > web site? How do you suggest to consider what articles should live on > the wiki, which - on documentation site? How these two sites are going > to be related? These are very good questions. I think initially we can provide a menu option on word press to redirect users to the docs site. Other pages may contain references residing on the docs site much as we do today with the Wiki. As for deciding what goes where, unfortunately I do not yet have an answer. My inspiration for this project has been the Jenkins project who as far as I know have retained their Wiki. We could probably look to them for an answer to this question. Michael __
Re: [OpenIndiana-discuss] OpenIndiana Docs (proof of concept) - What is it all about?
>From an outsider's perspective, I'd like to thank you, Michael, for the effort. I was a sometimes-user of Solaris at an old job, and I ran OpenSolaris on my laptop when it first came out. I enjoyed it, but as someone who just checks in on OpenSolaris-alikes every now and again, I'm very unclear about what of what I learned on the old systems apply to what is being produced now - and I'm eager to learn more. Your doc project seems like the logical method for those things to be answered. I gather that you got feedback that was critical of your effort. I didn't see those messages, so I'm not responding to them. I'm just thanking you for your effort; I agree that documentation is hugely important, and even if your docs are not accepted as "official", I do hope you continue with the effort. Cheers. -- kla...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [oi-dev] OpenIndiana Docs (proof of concept) - What is it all about?
Hullo, Thank you Michael for this very well written and nuanced message, it surely gives more context to your proposal. As I am an early follower of your reflexions on documentation and we had the opportunity to exchange ideas, my reaction to your proposal can only be positive. > Having said all of that, let me turn the discussion back to my little docs > website proof of concept. For starters, it's not a submarine project, nor > do I intend to apply any kind of licensing which may restrict it's reuse in > any way. Frankly I could care less how it's licensed. I wrote it all for > the pure joy of writing. And in the spirit of community, it's free and > available to all. > Straight to the point, I should mention that several discussions by email and on #oi-documentation were preliminary to your initiative -- to gather context and input -- which hopefully contributed to your reflexion. > As for how it evolved the way it did, there are a number of reasons. > > As soon as I joined the project I began looking at the OSOL docs, the > website, and the wiki, and took notes of my thoughts and observations along > the way. Those notes are publicly available for anyone to see: > > https://github.com/makruger/openindiana-docs > > The README describes what's in each document. This is all public and has > been for quite some time. Again, not a submarine project at all. > > So, after looking at the current state of information management, several > things became clear. > > There needed to be a way to: > > 1) Place documentation under distributed version control. > 2) Lower the bar of entry to the documentation process. > 3) Make changes and quickly deploy those changes in some kind of automated > fashion (e.g. continuous integration). > 4) Present the documentation in an organized and aesthetically pleasing > way. > I cannot disagree with any of these points. In my successive research environments, documents were written exclusively in LaTeX for scientific documents + manuals for numerical libraries or a markup language for code-related notes, all of them under revision control system. Even applications for fundings or student thesis drafts are shared in a GIT repository and contributed to by collaborators with merge requests. My experience tells me that the argument against source files under revision control for documentation does not stand. > > It's been said that a project lives or dies by it's documentation. Whether > that's really true or not, I don't know, but the general perception for > OpenIndiana is it's largely an undocumented project. > One may argue that the reality is different but the point is that even if the documentation exists, the perception is more important because it may reflect the fact that: - part of the information is outdated making it difficult to distinguish what is applicable and what is not, - information is not visible or does not present a structure/hierarchy that makes it effectively usable, - interaction with the medium is flawed (impossibility to display), - content cannot be searched (impossibility to index). > > The need is there, now it's just a matter of coming up with a workable > method for addressing the need. Good docs are important. Just as important > is way the documentation is organized and presented. > > This leads me to state the obvious: > > The current state of the wiki is quite poor. The content is poorly > organized, largely outdated, and the navigation menus do not function at > all on mobile devices (this included tablets). This is a real problem, > especially if the project expects people to rely on the Wiki as the "go to" > source of information about the OpenIndiana project. > > I can only conclude by saying this is quite unacceptable and something > better is required. Whether that something better is my little project, or > something else entirely, that's for the community to decide. > I came to a similar conclusions when I started contributing to OI and I also think that having a collection of source files written in markup format allows generation to other formats and media than deployment to a website, e.g. generation of a PDF of the Handbook that can been readily shipped with the distribution together with a static HTML version. > > My proposal is on the table and I can only expect it to be fairly judged > on it's technical merits. It should not however be frontally assaulted > because it differs from the way things have always been done. > I would also highlight the fact that being a technological demonstration, any other concern is orthogonal to the current proposal and as such, while being pertinent for an hypothetical final implementation, should be considered in a next stage. We all liked the OpenSolaris books but they are not tractable by such a small community and the Wiki has too many technical shortcomings for end-user documentation. As I mentioned to several people, I see this initiative as the documentation counterpart to oi-u
Re: [OpenIndiana-discuss] OpenIndiana Docs (proof of concept) - What is it all about?
Hello, Too many times there have been devastating discussions about getting Firefox > ready on OI and if or not one should bake pizza's to create the code. While > on the other hand updates for every day used server programs are not > available. > This is the case if you use 151a which has been unmaintained for a while due to lack of interest and consequently contributions. > For server usage in a professional way OI is lacking more and more security > updates, only if you use the hipster or hipster2 or no wait the > hipster-hipster version. (I lost track of it) > Hipster being advertised as rolling-release, it is what it is... > I have long tried to use OI as a professional server but in December I > installed SmartOS and I went from hell to heaven. > I went from 7 days half-baked "make" "configure" "install" search and > destroy deployment nightmares to 15 minutes deployment. > If you use an unmaintained version and compile all your software, hell should be expected indeed. ;) > > There is only one big problem with SmartOS and that it has opensource > sourced by a commercial company. So there can always be a point in time > where the opensource will be closed or unreachable. > But at this moment Joyent flows there advantages back to the Illumos core. > (http://mail-index.netbsd.org/pkgsrc-users/2016/04/29/msg023314.html) so > even OI should benefit from it. > > So IMHO someone (preferable more than one) should build the bridge between > documentation scattered over illumos, solaris, smartos and Openindiana > websites and creators. > > This is my opinion, no insults intended. > There are known reasons behind the current situation and the existence of Hipster which I am not going to develop again but the bottom line is that Hipster is an attempt to overcome several difficulties. The rolling-release model may not suit everyone, this is a necessary step to adapt development of OI to the reality of existing manpower and try to regain momentum. Regarding the documentation, Michael's initiative is a good way to encourage collaboration since it is based on source files under revision control system, unlike a Wiki. So basically this may be one good candidate for building up a common resource. > > Br, > > Roel > > -Oorspronkelijk bericht- > Van: Michael Kruger [mailto:makruger2...@gmail.com] > Verzonden: woensdag 4 mei 2016 7:00 > Aan: OpenIndiana Developer mailing list ; > Discussion > list for OpenIndiana > Onderwerp: [OpenIndiana-discuss] OpenIndiana Docs (proof of concept) - What > is it all about? > > Now that the dust has settled a little bit after my initial presentation, > perhaps I should elaborate a bit about my motivations and intentions in > creating this little proof of concept. > > In the responses and discussions that followed, some feathers were ruffled, > and a number of points where raised, many of which could be distilled into > at least 3 distinct themes. > > I'll start by talking about the first theme as everything else hinges upon > it. > > > * Community conduct > * Project visibility > * Proof of concepts > > * Version control > * Hosting infrastructure > * Project marketing, SEO > > * Existing docs (OSOL Docs) > * Viability/Usability of Wiki > * dlc.openindiana.org/docs > * Documentation Standards (media types, etc.) > * Licensing/Contributer agreements/copyrights, branding etc. > > > It's now been about 3 months since I volunteered to help the project > with documentation. I have learned quite a bit and overall it's been > very interesting. I chose this project because it was very small, needed > people, and I thought I might be able to make a meaningful difference. I > still believe that. > > So, this is my creative outlet. This is a place where I can express > myself, learn, try new things, and explore new ideas. It's a place where > I can (hopefully) make a difference. > > Having a creative outlet is very important to me, because in my day job > I work for a government bureaucracy. There each department is it's own > little kingdom where nobody shares information or works together. As a > result, innovation is stifled and dysfunction is pervasive. Even worse, > most people are unhappy, and everyone complains. But the money is good > and my commute is very short, so I put up with it all. > > Here however, we're all volunteering our time. So I think having an > atmosphere of acceptance, civility, and respect is extremely important. > If not, the project will eventually curl up and die. > > However, before any of that happens, people may find themselves needing > to work alone or in small groups specifically and intentionally > excluding individuals with problematic behaviors. This will occur > because it's simply not possible to get anything done in an atmosphere > of hostility, jumping to premature conclusions, or where kvetching is > the rule of the day. > > This leads me to suggest there should be an OpenIndiana 'Code of > Conduct' to help reign in people with
Re: [OpenIndiana-discuss] [oi-dev] demonstration docs website
On 05/01/2016 07:30, Michael Kruger wrote: Hello all, Here is a little something I have been working to help showcase documentation for the OpenIndiana project. Currently hosted are: OpenIndiana FAQ (Complete, but still growing and improving) OpenIndiana Handbook (little more than a template at this point) OpenSolaris Books (41 titles from the 2009 redistributable docs release) Hi, Michael. Thank you for your work. To move further I think we should consider several questions... 1) Someone should look through the docs... So , reviewers are welcome. Have you changed "OpenSolaris Redistributable Books" in any way or just created the index and converted them to docbook? How do we mark parts of the books which are not currently actual? How are we going to update them (create new document or mark current document as reviewed)? How http://makruger.github.io/website/pages/docs/handbook.html and http://wiki.openindiana.org/oi/OpenIndiana+Handbook are related? What parts are missing? 2) What is the process of contribution, how site is generated? What tools are used to work on the docs ( asciidoctor + git ?)? 3) How do you propose to incorporate documentation site in current OI web site? How do you suggest to consider what articles should live on the wiki, which - on documentation site? How these two sites are going to be related? -- Best regards, Alexander Pyhalov, system administrator of Southern Federal University IT department ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OpenIndiana Docs (proof of concept) - What is it all about?
Hi Michael, I admire your dedication, knowledge and your love for OpenIndiana. But imho I think you are too late. OpenIndiana is almost near extinction. I have been on the mailing lists quite some time and questions and responses are declining rapidly. In my opinion this is caused by the separation of OI users in 2 groups: the PC/laptop OS users and the server users. Too many times there have been devastating discussions about getting Firefox ready on OI and if or not one should bake pizza's to create the code. While on the other hand updates for every day used server programs are not available. For server usage in a professional way OI is lacking more and more security updates, only if you use the hipster or hipster2 or no wait the hipster-hipster version. (I lost track of it) I have long tried to use OI as a professional server but in December I installed SmartOS and I went from hell to heaven. I went from 7 days half-baked "make" "configure" "install" search and destroy deployment nightmares to 15 minutes deployment. There is only one big problem with SmartOS and that it has opensource sourced by a commercial company. So there can always be a point in time where the opensource will be closed or unreachable. But at this moment Joyent flows there advantages back to the Illumos core. (http://mail-index.netbsd.org/pkgsrc-users/2016/04/29/msg023314.html) so even OI should benefit from it. So IMHO someone (preferable more than one) should build the bridge between documentation scattered over illumos, solaris, smartos and Openindiana websites and creators. This is my opinion, no insults intended. Br, Roel -Oorspronkelijk bericht- Van: Michael Kruger [mailto:makruger2...@gmail.com] Verzonden: woensdag 4 mei 2016 7:00 Aan: OpenIndiana Developer mailing list ; Discussion list for OpenIndiana Onderwerp: [OpenIndiana-discuss] OpenIndiana Docs (proof of concept) - What is it all about? Now that the dust has settled a little bit after my initial presentation, perhaps I should elaborate a bit about my motivations and intentions in creating this little proof of concept. In the responses and discussions that followed, some feathers were ruffled, and a number of points where raised, many of which could be distilled into at least 3 distinct themes. I'll start by talking about the first theme as everything else hinges upon it. * Community conduct * Project visibility * Proof of concepts * Version control * Hosting infrastructure * Project marketing, SEO * Existing docs (OSOL Docs) * Viability/Usability of Wiki * dlc.openindiana.org/docs * Documentation Standards (media types, etc.) * Licensing/Contributer agreements/copyrights, branding etc. It's now been about 3 months since I volunteered to help the project with documentation. I have learned quite a bit and overall it's been very interesting. I chose this project because it was very small, needed people, and I thought I might be able to make a meaningful difference. I still believe that. So, this is my creative outlet. This is a place where I can express myself, learn, try new things, and explore new ideas. It's a place where I can (hopefully) make a difference. Having a creative outlet is very important to me, because in my day job I work for a government bureaucracy. There each department is it's own little kingdom where nobody shares information or works together. As a result, innovation is stifled and dysfunction is pervasive. Even worse, most people are unhappy, and everyone complains. But the money is good and my commute is very short, so I put up with it all. Here however, we're all volunteering our time. So I think having an atmosphere of acceptance, civility, and respect is extremely important. If not, the project will eventually curl up and die. However, before any of that happens, people may find themselves needing to work alone or in small groups specifically and intentionally excluding individuals with problematic behaviors. This will occur because it's simply not possible to get anything done in an atmosphere of hostility, jumping to premature conclusions, or where kvetching is the rule of the day. This leads me to suggest there should be an OpenIndiana 'Code of Conduct' to help reign in people with troublesome behaviors. After all, such individuals effectively prevent others from achieving anything meaningful. The future of the project may very well depend on it. Having said all of that, let me turn the discussion back to my little docs website proof of concept. For starters, it's not a submarine project, nor do I intend to apply any kind of licensing which may restrict it's reuse in any way. Frankly I could care less how it's licensed. I wrote it all for the pure joy of writing. And in the spirit of community, it's free and available to all. As for how it evolved the way it did, there are a number of reasons. As soon as I joined the project I began looking at the OSOL docs, the web
