I'm hosting my application on a Linode, but is hosted on a Tomcat instance, which uses most of the RAM. I also have Apache installed, so I can front Mercurial, and I believe a bug tracker is a must, however I can't decide on which is best, given scarce resources. JIRA seems to be out of the question, so I've been deciding on either
Trac
Mantis
Redmine
I like Trac because I have already got Apache serving Python, Redmine for the features and Mantis because I feel it's the most lightweight of the three, however lacking in the feature department, compared with the other two, so, what do you recommend, given the situation?
I have a VPS and Redmine.
We used to have a 1 gig RAM, single v-core, 40GB disk VPS running Centos 5.5 (x64). It struggled with performance issues with Redmine under heavy use (since we also have our e-commerce websites running on the same box). We only have two developers that access redmine at a time, but we have enough apps that there were times that our FTP and Redmine and SVN access was slowing down the server and affecting our e-commerce customers (bad!).
We upgraded to a 2 gig RAM, two v-core, 80GB disk VPS. Chances are if we ever hire contractor software dev's and they use our Redmine and SVN we would probably re-size our slice to a 4 gig RAM, four v-core VPS. Still experimenting to see if 2 gig and two vcores is enough for us now. Basically you should be spending at least $50-$100 a month on your server for it to have enough to run redmine.
(Whats a VPS?)
That aside, do you really need to maintain your own bug tracking installation? We have moved our system from an inhouse Bugzilla to Assembla (www.assembla.com) and it is great! I have a lot more time to do my actual job these days instead of dealing with multi-tool integration problems. For the record I think Trac is part of Assembla's integration. We are a small organization so the Assembla fees are pretty light, I think we're up to maybe $25/mo (including all of our SVN hosting) so that's about 10 minutes of my time (wink;) and I was easily spending 1/2 day a month on tools issues. You'd have to scope it out to see if their offering makes sense for your organization. (BTW I don't work for Assembla!)
My apologies to give you a non-technical answer to your technical question.
Mantis is quite lightweight and works well on small VPSs. I would expect it to fit nicely on a 512M slice, and perhaps on an even smaller one, depending on your traffic.
I see that you believe it to be less featured that Redmine and Trac . That's another discussion, but the question is - does it do enough for your needs? If it does, you have a winner.
Related
How necessary is an Expression Engine software update for an existing website that works fine? I have version EE 2.11.6 and have been advised to upgrade to version 4 --at great expense.
I need the site to work for maybe five more years before I retire my business. It is a simple brochure site for a photography business displaying pictures and text with a blog and a contact form. Nothing fancy, no sensitive customer data, nothing of interest to hackers.
If I don't do the upgrade, is it really likely to stop working anytime soon? Would upgrading to version 3 instead of 4 give me a few more years?
Thanks in advance!
Dennis
whether it will keep working largely depends on your hosting environment. If your hosting environment stays the same, you don't want new functionality (ie plugins), and you have no payment systems involved, you could probably make this site stretch another five years. On the other hand, if your host wants to upgrade operating systems and PHP versions, eventually EE 2 will not be an option.
An upgrade to EE 3 is a big jump from EE 2. The jump from EE 3 to 4 is not nearly as difficult. What creates the cost in upgrading is often incompatible plugins. The EE 3 release changed the underlying code framework to the point that many useful plugins were abandoned and many developers decided to exit the EE marketplace. Finding replacements and re-working the functionality the plugin got you can be time consuming and expensive.
By the way, every site has something of interest to hackers. Your content is not necessarily the end goal, if they can get access to your server through some exploit, they can then use it to send spam emails, host a botnet, or use the computing power for their own purpose with obscured traceability. That can bring negative consequences for your site in the form of blacklisting and other penalties for being hacked.
Best of luck!
We are looking to implement an open source identity management system and have identified ForgeRock's stack as the best technology to implement.
The high cost of ForgeRock support and its per-User pricing model, however, is a potential roadblock. Our current User base is ~45K, but we expect to ramp up to 1M in the next 2 years.
So we're looking into scenarios where we proceed without FR Support. The lack of FR Maintenance releases would seem to put a damper on that, so we're curious if others have gone that route.
What has been your experience?
What kind of projects have you done this for? Size, etc.
In the absence of FR's Maintenance releases, have you been able to easily create your own patches?
What are some potential pitfalls?
If there are blogs or other communities that deal with this topic, please point me in their general direction.
Thanks.
As a community user I did use OpenAM(/OpenSSO) and OpenDJ for the past 6 years or so, but it was a very small deployment (10k users only 1 server instance from both products).
1) In the early stages we did have reliability issues with OpenAM, which we mostly resolved by restarting the server instances - clearly wasn't preferred, but we didn't really spend too much development effort on actually trying to resolve it (plus lacked the necessary knowledge for investigation back then). After spending some actual effort on trying to learn the product it turned out that the most of our issues were either self-inflicted (badly written customizations, or misconfigurations), or was actually something that got recently resolved in the OpenAM project and was relatively simple to backport to our version.
Of course the experience itself largely depends on how often you want to make configuration changes in the deployment though, since we weren't changing a lot of things over the years, OpenAM just worked nicely for long intervals without requiring any kind of maintenance.
3) Since we didn't really ran into new issues (the config barely changed), there weren't too many surprises after a while. The security patches were mostly simple to backport and didn't cause too much trouble (It did help that after 1,5 years I became a FR employee and I actively worked on OpenAM issues though :) )
4) I think running without subscription has its risks, but they mostly relate to:
are you planning to roll out new features based on OpenAM functionality during that 2 years (i.e. are you planning to constantly make changes to the deployment)?
do you have good developers to work on these features? Working with OpenAM for example can quite easily require you to have a look at the source code to figure out how things work, the quality of the documentation has improved a lot over the years though. Regardless, backporting fixes are going to be more and more difficult over time, as the releases will differ a lot more (since the development team is getting bigger and bigger for each projects) - and even then you can't just assume that all the issues you run into are by definition already resolved in trunk. The need to resolve some of the issues on your own is a cost/risk you need to take into account.
what kind of SLA do you want to have for your deployment? Is your business going bankrupt after a 1 minute outage? Is it acceptable to just frequently restart your service (in case you run into some weird issues)?
do you really need support for all 3 products? For example my background would allow me to work easily without OpenAM support, but I would be in the deep end if something is going wrong with my provisioning system...
And a generic remark:
Having user growth of 20x within two years sounds a bit unrealistic, or very hopeful at least. Maybe what you should look for is a 1 year subscription for a bit more reasonable target number and then have a renewal once you have a better understanding of customer growth in your business?
What I am looking specifically for is software thats runs on Linux (CentOS) that can do the following:
Show human readable CPU, Memory, Disk, Apache, MySQL utilization/performance.
Provide historic reports on the above metrics (today, week, month, year etc...)
Provide this data in an easy to view web based report or at least exportable to excel/csv.
I have looked at Cacti and I don't think its really an enterprise solution. I don't care if this is free or paid for software, though open source would be nice I am really just looking for the best solution.
Does anything like this exist for Linux? The problem this company is faced with is we have no way of measuring how the changes we make in our code and server configurations impact overall performance. So when I saw lets do this - then do it, I can't shows the benefits or revert back cause it was a negative in terms of performance. I am not a linux guru, just a developer with some linux skills, but am open to all suggestions. Thanks for reading.
Even though there are lot of open source projects but the main drawback they suffer is that they are away harder to configure. I have some across a free to called SeaLion which is way easier to install and configure. And it has awesome timeline base to representing outputs. Also there are different paid tools line new relic, server density, solar wind which you can also give a look.
Check out the eginnovations monitoring tool
http://www.eginnovations.com
Monitors Linux, Apache, mySQL and other applications and is web-based, so you dont have to be a linux expert.
M.
Cacti is a simple one. OpenNMS is more complete.
You are not limited to linux, using SNMP you can fetch this data from a remote host and use any NMS you like.
IMHO one of the best "freemium" tools is Zenoss (http://community.zenoss.org/).
The community edition is free. It will do everything you need, and comes with a simple RPM based installation process. It's a lot easier than Cacti or Nagios to setup and use. I would give it a try.
I use munin. I'ts much much simpler to set up than cacti. It's better to compile it yourself than pull it with apt-get (or other) because that way it has more built-in data-gathering scripts.
Basically there is no single dashboard where you can get all reports metrics. There are a range of opensource softwares which and can serve your need.
For server performance many people recommends munin, you will have to learn how to read teh report data. You can also write custom scripts to get certain report parameters of Mysql. Additionally if your server host provides an API, you can then do lot more related to reports in your admin panel.
you have a look at following url which can provide you more idea about choosing best fit to your need.
https://serverfault.com/questions/44/what-tool-do-you-use-to-monitor-your-servers
http://sixrevisions.com/tools/10-free-server-network-monitoring-tools-that-kick-ass/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I know this is an odd question but I need to ask it to get information to present to a client. Their lead network admin wants me to work on 30 day trial servers like Sharepoint & SQL Server to develop projects for their clients. While I will do as they ask, I'm not convinced this is the best way to go about developing software or troubleshooting previously developed software. To be honest, I've never worked on custom development for any server/software using a trial version.
What arguements are there for and against working on trial software/servers?
Pro: It enables you to mock up a concept and see if it seems like the development path will be easy before you shell out large amounts of money for the real deal.
Cons: It could trap you in a vicious cycle of wiping your virtual machine and re-installing the OS, the trial version, and your product (you do use source control, correct?) if they are hoping that this will alleviate the need for ever paying for the real product.
Suggestion: If you don't mind unsolicited advice, then I would determine why the lead admin wants to use the trial versions -- and then go from there. Until you know the reasons you cannot respond to them.
If they are doing it for the pro reason, then determine if you feel comfortable working with the possibility of switching technologies 30 days into your build. (Can you do it efficiently?)
If they are doing it to avoid spending money, present some of the alternate open source / free options that you are comfortable developing with. If they will not change their modus operandi at that point, then do what is necessary, knowing what you will be walking away from / getting in to.
(And if you don't mind one more bit of unsolicited advice -- if they are doing it for the con reason and will not change WALK AWAY)
Point them at BizSpark. Microsoft is begging people to use their stuff. A hunny will get you everything on the map for 3 years or until you start making money.
Oh, to answer your question: If I need to get funding for technology not present in the infrastructure or to do a proof of concept I would not think twice about using evals. That is what they are for. I would be evaluating the suitability of the product for use with my designs. Seems easy to me. Maybe I am just, hold on, i have to give my parrot a cracker... ;-)
Apart from the ethical arguments, there are practical ones:
What are you supposed to do if development overruns? Start reinstalling everything, wasting several days doing so?
Additionally, if the client is so strapped for cash that they want to do this, how can you be certain they will pay you (either due to cash flow problems, or simply because of their shady ethics)?
I'm pretty sure that that kind of use is a violation of license terms. Trial editions of servers are for evaluating a product. And if you are in fact creating a product, then you have gone way beyond evaluation.
I would never work under such terms. If you are developing a concrete product, get proper licenses for the development tools. I know that the developer edition of SQL server is not hugely expensive (compared to a version licensed for production use), so I would imagine that the same counts for Sharepoint.
And then there is of course, as already mentioned, what do you do when the trail period expires?
I wouldn't mind doing this so long as the job is shorter than 30 days. Make sure your work contract they're paying for the time worked and not specific deliverables, because your deliverables are time-bombed.
Also be prepared to walk away. If this company doesn't have resources to get the right software, you don't want to be there longer than 30 days anyhow.
Microsoft provides several pre-built virtual machines, that contains full stacks.
(Server 2008/Sql 2008/Sharepoin) (Server 2003/Sql/Project Server) etc.
They are time bombed, but often (not always) Microsoft will provide a new image after the time out.
The benefit of using these images is that they are already configured and good to go.
As an example here is a beta of sharepoint 2010 (http://www.microsoft.com/downloads/details.aspx?FamilyID=0c51819b-3d40-435c-a103-a5481fe0a0d2&displaylang=en).
If the project has a quick timeline, it provides the developers access to the configured stack right away, with no ramp up time of building new virtual machines.
Esp when working on beta/early release software this is great.
The SQL Server evaluation's download page mentions that the evaluation license is good for 180 days, and specifically advertises it as a tool you can use for mission-critical applications. This tells me MS is fine with your using it for development work.
To answer a question with more questions:
How long does this project run?
What phase of the effort are you in now?
Is this an internal/proof-of-concept project, or something that your customer(s) will be using for a long time?
If you are going to need to use SQL Server for Operations & Maintenance support months past the initial evaluation period, you ought to get a license for the full version of it. And also consider what your customers are using so that you can reproduce any bugs that come back from them.
I don't think it's ethical to continually renew evaluation licenses to have a longer evaluation period. Companies call them "evaluations" as a try-before-you-buy, not a keep-trying-without-buying.
I'm not sure what others are seeing as unethical here. If the project is short enough to be completed within the 30 day trial, I don't see any issues. I think that's a great use of trials - if they can't handle a clients applications then they aren't a good option and you can use something else.
I think others here have given some good advice regarding the longer than 30 days projects and some good contract ideas.
How in-house do the servers have to be? Would a hosted solution work for them? (Dreamhost, Amazon Web Services, whatever)? Some hosting systems provide pretty complex machine images (lots of stuff pre-installed--definitely AWS, presumably most others), decreasing setup time/effort. I think those come with licenses, though I don't honestly know. Plus, in at least some cases, you (they) only pay for what you (they) use.
Obviously no good if the physical machine needs to be in-house, or if things are otherwise super-sensitive.
I'd like to start a free budget/personal finance site and will need plenty of horsepower and storage. I'm definitely a nubee, so how does one get started in terms of hardware infrastructure? Do I need to get a dedicated IP from my ISP and obtain my own servers? Do I go with amazon or Sql Server Data Services/Azure or something like that? Is the latter services free or a discount offering available to non-profit/free services such as the budget/personal finance site I'm looking to start?
If you don't mind writing your web application in python, then I's suggest using Google App Engine. See: What Is Google App Engine?
What I like to do when I have new ideas for a site is to find an inexpensive hosting solution ($10 per month). This allows me to test the idea and see if the site is going to be successful. If it is a flop, I haven't wasted much money and if it is successful I can upgrade to better hosting (dedicated server).
There are many hosting options available and several of them have great tools such as an online SQL Server management studio. Your other option would be to host it yourself if you are prepared to deal with firewall issues, backups, storage, etc.
Whether it is feasible to DIY varies a lot by country...if you have a decent broadband connection with a fixed IP this can be the cheapest route to play around with first, especially if you need an awful lot of storage.
Note however that many fast broadband connections are only fast for downloads - when you're running a server, the speed your users will see is the upload speed, which is usually a lot less. Also, you'll need to do your own admin and backup etc.
Apart from this most hosting options have a price tag on top, varying from virtual hosts (sharing a real machine), to colocation (your machine in somebody's data center), to cloud services like amazon et al (which have a good scaling ability)- and you will need to shop around for the software stack and hardware features you really need.
There's really two ways to answer this question, what differentiates them is budget.
One is to properly design this solution, prototype it, benchmark the prototype, extrapolate anticipated user load, add overhead and scale accordingly. This takes time, costs but gives you a supportable solution that serves your customers well.
The other is to just give something, anything a go and fix the problems as they come along. This is quicker and cheaper but might be a headache for a while and might p*** off your customers.
Basically it comes down to budget.
Best of luck.