Tag Info

Hot answers tagged

112

The red prompt is a good idea, which I also use. Another trick is to put a large ASCII-art warning in the /etc/motd file. Having something like this greet you when you log in should get your attention: _______ _ _ _____ _____ _____ _____ |__ __| | | |_ _|/ ____| |_ _|/ ____| /\ | | | |__| | | | | (___ | | | (___ ...


57

Not quite the same thing, but this web site recommends having your developers wear a pink sombrero when making changes to production systems. You could probably have a similar rule for sshing into them.


44

The biggest I've used is a discrete naming-scheme where prod-systems are named obviously different than test/dev instances. This makes the "Username@Hostname: " style prompt visibly different. And by obvious I mean more than just different words, different formats too: example: PRD-WEB001 vs DEVEL-BOB-WEB001 This has several things going for it: The ...


26

I would recommend using a mixture of Debian pre-seeding, where you give the installer a text file that answers all the questions it would ask, and Puppet. THe reason for using the preseeding, rather than FAI is that you don't have to set up an image first and deal with keeping it up to date. You will end up with an install very similar to what you would ...


22

You can survive just fine with the 32 bit CentOS install. But, like the warning says, using a 32 bit OS means that MySQL can't actually use all (or even most of) the RAM installed in the system. Seems like a waste to me. If the hardware supports 64-bit, I'd certainly replace the 32 bit OS with a 64 bit one, yeah. You'd probably want to do some testing ...


21

One thing you need to keep in mind is that this needs to be a persistent reminder, not just an indicator at login time. Very often, someone will have several shells running at the same time in different tabs and move between them. Some will be dev, some production. So when you are running a command, you need to have an indicator at that point. So having a ...


18

Generally speaking speaking security updates are considered to be somewhat safe, particularly for a distribution with goals like RedHat. Their core focus is creating an operating environment that is consistent. As such the maintainers tend to pick versions of packages and stick with them for the long haul. To see what I mean look at the versions of such ...


18

Titles are just titles. From what I have seen they are not really standardized, so you want to go with what sounds like what people will be doing. I personally don't like the title Engineer in CS, but that is always debatable. My recommendation would be to go with "System Administrator." The nice thing about a vanilla "Systems Administrator" title is that ...


16

I have a similar setup, except with Xen in place. I have been very happy with a combination of: Nagios for alerting (using PNP for some lite graphing, and Nagviz for a service state dashboard) Ganglia for historical graphing of systems OSSEC as a HIDS and equally importantly as collector for centralized logging sidenote: There is a Splunk plugin for ...


15

SQL Server, and most other products, generate the counters all the time, no matter if there are listeners or not (ignoring the -x startup option). Counter tracing is completely transparent on the application being monitored. There is a shared memory region on which the monitored application writes and from which monitoring sessions read the raw values at the ...


14

IIS supports xcopy deployment so just copying the files should be all you need unless you have special requirements. One way to do it is a simple script that uses ROBOCOPY to copy the new files to the server. If the site is large and this takes too long, use a version control system. I like Mercurial for this purpose, although you have to be careful that ...


12

Consider using the Web Deployment Tool from Microsoft. It was specifically designed to help deploy web applications and updates to those web applications to production IIS 6 and 7 web servers and it does a better job of the task than MSI (Windows Installer), IMHO. Normally you use it by setting up a "gold master" site somewhere and then telling the tool to ...


12

I use the openSource bacula. It is excellent - server/client model that works on windows or linux. There is good online support, and an active developer community. A bit tricky to set up, but has all the features you could ever want. There is also a nice web gui called bweb that can be used for day-to-day operation of it.


12

There's nothing wrong with running perfmon on production boxes. It's relatively low key, and can gather a lot of good info for you. And how would you accurately simulate production loads if you didn't run some analysis on the production server? From Brent Ozar in your own link: Let Perfmon run for a day or two to gather a good baseline of the ...


12

Just consider that your second and third ideas help during the initial connection but are of no value when you have multiple terminals open and move from one to another. sysadmin1138's idea of using naming is good when it can be applied but there are plenty of cases where it cannot be. The only thing I've found to be really worthwhile is a coloured prompt. ...


12

Maximum virtual address space of a 32 bit binary is 2^32 (4GB) - once you hit this limit, you're going nowhere. Should you switch to 64-bit? Absolutely. Not only will you no longer hit the memory barrier, the generic 64-bit instruction set has generally better performance than generic 32-bit (due to the sheer age of x86) and thus, switching to x64 will ...


11

These are my suggestions: 1) Make sure most commands (rm, chown, chmod, /etc/init.d/* ) on the Production environment require sudo access 2) Use PS1/PS2 to indicate that the user is in a Prod server bash-3.2$ export PS1="[\u@\h \W]\$ " This will show the command prompt as [sridhar@prodappserver901 conf]$ 3) If Using Putty/SSH clients, You can always ...


11

I suggest you evaluate this in terms of business/operational risk. Using old, unsupported software often caries these potential risks. No vendor support No updates to bugs No security patches OS updates may be incompatible Disaster recovery options may be limited. Licensing issues can cause recovery/operational problems. Inability to scale/expand ...


10

You should never touch anything in production unless there's a good reason to do so. Security updates are a very good reason. And as Iain mentions, testing beforehand helps you to ensure that nothing is likely to go wrong when you apply the updates to your production system.


10

The red/special command prompt is good. Another thing might be a quicker auto-logout on those machines using the TMOUT variable. If you have opened many windows the production ones will go away faster. This should lead to a different behaviour: Develop Test Make your changes to a staging server Only then make a quick dash to production and deploy there ...


10

You can use something like dd if=/dev/hda of=/tmp/path/server.img then use QEmu's qemu-img convert -f raw -O vmdk server.img server.vmdk (replace vmdk with vpc and the file extension with vhd for Xen or Hyper-V) Otherwise most virtualization environments have tools to do what you want, this is just one way.


10

Puppet is a more recently-written tool, written in Ruby, that is gaining ground against cfengine.


10

I configured Zabbix on a virtual machine at Slicehost and have been quite pleased with the solution. Since it's physically separate from our production servers it will alert me even if the production network has issues. The virtual machine at Slicehost is cheap and easy to backup. Zabbix is great because it can monitor website response time and also CPU, ...


10

I'd recommend CFengine for any environment which is more than 2-3 boxes and where you have some concept of 'templates' or servers performing specific roles. Why? Simply put it reduces mistakes, you have a tool which will ensure file/directory permissions are correct everywhere in the environment and when you come to roll out more servers, the tool handles ...


9

Plurk.com uses Node.js for their Comet engine, they have a fairly high traffic load too. Blog post about Plurk using Node.js


9

Reinstall is the best option. I personally would always have the nagging feeling of something not done right even if the following work. Use another Ubuntu system to reference your permissions. Same Ubuntu version and architecture. reference$ find / ! -type l \ -path "^/tmp" -prune \ -o -path "^/dev" -prune \ -o -path "^/sys" ...


9

The Mac Mini is well capable of hosting a low to medium traffic website. The MAMP stack is a problem, though. MAMP is really only meant to be used for development. They configure the security settings in MAMP as to not get in the way of development. Using it in production is asking for problems. You'd be much better off installing the "real" versions of ...


8

Since node.js has not been around long enough to have satisfied the greater community that it's stable and secure, many production deployments use Apache or nginx as a web server that proxies http requests to node running on a different port that is not accessible from the machine's public IP address. Also forever may be able to help with the node stability ...


8

You can't. My suggestion is to not replicate production to staging, but to occasionally rebuild the staging database with one of your production backup files. Then you're working with production data (albeit a few hours or days old) but changes you make on staging won't affect production. EDIT: With your edit, this is now a significantly different ...


7

Here's a bash function that can be sourced from .bashrc to add a warning when you use rm with more than 2 arguments: unalias rm 2>/dev/null real_rm=/bin/rm rm_opts="" function confirm { echo -n "Do you want to continue (Y/N)? " read v v=$(echo $v|tr '[a-z]' '[A-Z]') if [[ "$v" == "Y" ]]; then return 0 elif [[ "$v" == "N" ]]; then ...



Only top voted, non community-wiki answers of a minimum length are eligible