Recent Posts

Pages: [1] 2 3 4
1
Your program repositories on CentOS (and other Red Hat / RPM-based systems) as well ass Debian, Ubuntu (and other systems that uses the apt-programs for management of installed programs) use cache.

This local cache can easily grow HUGE.

It is a good idea to clean this space up. If you are running out of diskspace - try this first and before ordering more diskspace (maybe you dont really need more space but only need to remove unused files).

1. The YUM way:
On systems running CentOS, Fedora, Red Hat and similar you can install the package yum-utils (yum install yum-utils) and then run:

yum clean all

You can also run package-cleanup --leaves --all

check the man pages and help texts for more information about these programs. On a typical webserver type installation that has been running a while you could easily clear up a couple of gigs by running this. Try it, it only removes stuff you dont really need anyway!


2. The APT way:

On Debian, Ubuntu and similar systems you can use a similar program;

apt-get autoclean

Also check the manpage and see if the purge alternative maybe be useful for you.

To see how much diskspace you have you run df -h ("h" means "human readable, ie a more user friendly way of presenting disk usage by the program df). If you still need to free more diskspace - use the df-program and see which files and directories take up the most space. Use bz2 (bzip2) to compress files and see the man page for bzip to see how to tweak and compress the files the most on your system - this will save a lot of space. Old logfiles is an example of files that typically grow large but can be decreased SIGNIFICALLY (!) by simply compressing them.

2
En mycket stor majoritet av alla som hör av sig till vår support och har problem med sitt e-postprogram använder någon av Microsofts e-postklienter, lustigt nog är de dyraste programmen de som verkar orsaka flest komplicerade problem men faktum är att alla Microsofts e-postprogram är rejält överrepresenterade.

På vår supportsida, http://www.compartment.se/support ,  finner du mer information och länkar till resurser med tips på lösningar på konkreta problem. Här summerar vi lite vad som brukar vara problemet och hur du kan lösa dem på ett enkelt vis.

Exempel på e-postprogram som ofta orsakar krångliga problem:

 - Outlook (samtliga versioner)
 - Windows Live Mail
 - Windows Mail
 - Outlook Express (ej lika vanligt förekommande längre, använder du detta prorgam kanske du gör bäst i att uppgradera till ett modernt e-postprogram som tex Mozilla Thunderbird på Mac, PC, Linux och Unix eller Apple Mail på Mac, Mail på Android eller använda Webmail).


Några vanliga grundproblem:
 - Anslutning till e-postservern börjar plötsligt krångla (time out) och eventuellt krashar e-postprogrammet frekvent.

 - All mail försvinner. Ofta i kombination med att e-postprogrammet krashar och eventuellt inte går att starta på nytt.

 - Skadade PST-filer ("profil-filer" i datorn) som måste repareras med förlust av all lokalt lagrad e-post som följd.

 - "Ange lösenord för nätverket" och liknande felmeddelanden som egentligen är "bogus" och har att göra med att inställningar i windows gått sönder.

 - Problem relaterade till uppdatering eller installation av program som tex säkerhetsuppdateringar av windows.


Några vanliga lösningar på problem:

 - Vänta och se om det blir bättre samt starta om programmet och eventuellt starta om hela datorn.

 - Kontrollera om inställningarna har förändrats (eller behöver förändras).

 - Uppdatera alla programvaror.

 - Kontrollera antivirusprogram och liknande säkerhetsinställningar, även för nätverket.

 - Byt till ett bättre e-postprogram. Tragikomiskt nog så är det i regel de e-postprogram du inte alls betalar för som verkar fungera bäst, exempelvis Mozilla Thunderbird (som är helt kostnadsfritt att ladda ned för såväl Mac och andra UNIX-liknande plattformar som Linux och Microsofts operativsystem för dator), Alpine (för linux/unix), Evolution, Mail (i Apple eller Android) är några exempel på program som vi i regel hjälper våra kunder att ställa in en gång och sedan inte hör något från kunden annat än om de byter dator och har tappat bort dokumentationen med inställningarna.


Visst kan det kännas tråkigt att inte kunna använda dyra mjukvaror som ert företag betalat mycket pengar för men om man vänder på det och ser det så här istället: Hur mycket får det kosta i tex produktionsbortfall? Är det inte bättre att använda ett epostprogram som fungerar?

Vår support har lång erfarenhet av i princip varenda tänkbar kombination av mjukvaror, varför inte kika på något av våra IT-supportavtal för att få bästa möjliga hjälp på det sätt som passar er arbetssituation?

Läs mer på compartment, http://www.compartment.se/

3
Problem: you have a number of files in a directory, now you want to overwrite all of them with one single source file.
Since the command cp (copy) only copies to one file at a time you need to invoke cp multiple times and actually do a copy (overwrite) several times, once per existing file.

In bash you can overwrite multiple (existing) files in a directory. This works in most Linux distributions and should work in most BSD's as well:

# ls | xargs -n 1 cp <source file>


what the command does is actually:

1. ls lists all files in the directory and pipes it to xargs
2. xargs runs once and copies the source file in order to overwrite the original fil.

Result: you have the same files names existing in your directory but now each file contains the contents from the source file.

:)
4
Detta forum är inte en FAQ. Du vet väl att vi har en separat FAQ, se tex här: här http://faq.compartment.se/sitemap/C/sv.html - vi har nyligen uppdaterat vår FAQ så ta gärna en titt, hittar du inte det du söker kan du skicka en fråga till oss via FAQ:n.

Aktuell information hittar du även på compartment.se
5
Svenskt supportforum / DNS-Manager
« Last post by hostmaster on May 24, 2013, 06:19:31 pm »
Använder du vår DNS-Manager, som antingen kan kopplas till en fristående DNS-tjänst eller till en DNS-tjänst som ingår i exempelvis en Webhotelltjänst, så får du lite tips och råd i denna forumtråd.

Rent generellt så kan det vara en god idé att ha i bakhuvudet att precis ALLT som har med er/era domäner att göra är beroende av att DNS fungerar, hela tiden, dygnet runt, året om. Ett fel i DNS kan släpa efter och orsaka mycket problem. Att teckna gärna något av våra IT-supportavtal för att få experthjälp för bland annat domännamnsfrågor och DNS är en god idé. Att tänka igenom och planera i förväg inför en omstyrning i DNS är också mycket viktigt. Här har vi också mycket kunskap och lång erfarenhet som vi gärna delar med oss av för att ni ska få en så bra tjänst som möjligt!


I DNS talar man om olika poster eller 'pekare' eller 'records'. Kärt barn har många namn. En post kan exempelvis vara en MX-pekare som talar om för hela världen vilken mailserver som de ska leverera mail till om någon vill skicka e-post till er domän.

Som alltid är det A och O att ha redundans. En enstaka e-postserver är lika dumt som en enstaka namnserver. Kontakta gärna vår support så berättar vi mer.


Tips & Råd kring DNS-Managern
Utöver det som redan nämnts ovan så är det en god idé att till att börja med bara göra en ändring i taget, skapa en pekare, spara och testa.
Fungerar allt som det ska och du inte får några felmeddelanden så har du förstått galoppen, i annat fall, gör om eller kontakta support för att få hjälp.

Så snart du sparat en ändring så "trycks den ut" i vårt nät, det går i regel mycket snabbt men kan ta något längre tid exempelvis vid underhållsarbeten, slår ändringen inte igenom direkt så är det TTL-tiderna som gäller och som påverkar hur länge informationen sparas. Alla DNS-svar skickas nämligen tillsammans med en TTL, dvs en 'cache-tid' som talar om hur länge svaret får sparas.
Svaret sparas i regel hela cache-tiden vilket innebär att om du klockan 8 på måndag morgon ska styra om www.dindomän.nu från en IP-adress till en annan och har en TTL på 8 timmar så kommer det att ta 8 timmar tills HELA Internet förstått att hemsidan är ompekad. Dock kommer folk "ramla in" på både den gamla och den nya IP-adressen under denna 8-timmarsperiod och eventuellt en kort stund efter att 8 timmar passerat.

Således är det en god idé att ställa ned TTL:en till tex en timme redan kvällen innan (minst 8 timmar innan ompekningen), på detta sätt så behöver ni bara ha hemsidan aktiv på båda IP-adresserna (eller motsvarande) under ca en timme.

Det samma gäller ompekning av alla typer av tjänster, inte minst e-post.

Vi rekommenderar att man alltid behåller den "gamla" tjänsten parallellt med den nya som man pekar om till i minst en vecka efter en ompekning. Varför en hel vecka frågar sig många? Jo, det finns många skäl till detta:
 - Du har missat någon detalj i den nya tjänsten och behöver styra tillbaks till den gamla tjänsten. Detta blir svårt eller omöjligt att göra om du ej har kvar båda tjänsterna parallellt.
 - Det finns alltid enstaka "eftersläntrare", särskilt när det gäller "viktigare tjänster" som e-post, e-handel, webplatser mm så är det viktigt att 'fånga upp' tex e-mail som levereras till dem gamla mailtjänsten, även om det är fel att leverera dit, men avsändarens e-postsystem - hur dysfunktionellt de än må vara - har ju trots allt ett e-mail att leverera till er och om ni inte fortsätter att "svara" på den gamla adressen så går ni miste om informationen. Tänk på att vittja e-post både på nya och gamla mailservern då och då under denna vecka.
 - Det är lätt att göra en driftsäker omstyrning, varför inte göra det enkelt för era kunder, användare och besökare? Att komma till ett felmeddelande istället för er websida ser aldrig bra ut och det är onödigt att hamna i det läget.

6
En stor födel med Nidavellirbrandväggarna jämfört med andra system är att du kan välja inte bara på ett sätt att på detaljerad nivå prioritera olika typer av trafik, olika protokoll osv utan du kan faktiskt använda flera olika metoder. Olika driftsituationer ställer olika krav och ibland kan ett verktyg göra jobbet bättre än ett annat så det kan vara skönt att kunna välja mellan flera olika alternativ.

Med detta sagt är det en god idé att börja med det alternativ som presenteras som standard eller "förvalt" när du ska börja experimentera med trafikprioritering första gången. Sätt upp en test-server och prova att begränsa, prioritera och skicka trafik igenom för att se vad som fungerar bäst.

I fallet IP-telefoni så finns bland annat en IP-växel som en virtuell applikation i vår virtualiseringstjänst http://www.compartment.se/vps om du vill testa med lite IP-telefoni, med rätt inställningar kan du få riktigt bra samtalskvalitet och ändå använda ned till en tiondel av bandbredden som andra lösningar behöver - tack vare smart trafikprioritering.

En grundregel är att du behöver full bandbredd för varje samtal som pågår - eller står i kö - och all denna trafik behöver prioriteras. Sätt upp en separat brandvägg eller åtminstone ett separat interface på brandväggen för ett separat IP-telefoni-LAN så att du kan reservera en viss mängd bandbredd för alla era samtal.

7
Absolute, minimum (might be painful!) for a couple of popular OS:es (virtual, a physical server usually needs more):

Cent OS 5 32-bit: 512MB (painful! go for 1GB!)
CentOS 5 64-bit: 512MB (really, go for no less than 1GB!)

Centos 6 32-bit: 512MB (se above)
Centos 6 64-bit: 1GB (or more!!)

Also use no less than 2GB hard drive (CentOS 6 uses up a full 2GB for a minimal install)

Debian 7, 32/64: no less than 512MB.

Also, since debian comes with over 29 000 maintained programs available to install - if you plan on using these, get the diskspace needed to run and install these - do not forget that your /tmp space needs to be as big as the files you are working with . ie if you are gunzipping a copy of a 1GB tar file that resides in /home normally you need more than 3GB to handle this file (1GB for the original file, 1GB for temporary space and space to unpack the archive).

Ubuntu 10.04.4 LTS 32-bit: 256MB, no less!
Ubuntu 10.04.4 LTS 64-bit: 264MB, not less (but more! yes!!)

Ubuntu 12.04 32-bit: absolutely no less than 512MB
Ubuntu 12.04 64-bit: no less than 512MB, prefferably a couple of Gigabytes and a multi core system.


32- or 64-bit? You usually get "more out of" the CPU when using 64-bit compared to 32-bit. How ever many users report that a 32-bit system uses less RAM. Typically your average linux server is not working with a lot of heavy computing - for example a webserver is "more" in need of  a lot of fast RAM than many fast cpu cores. How ever, probably at least two cores is minimum.

Every now and then you do need your heavy computing, compiling programs (such as installing security updates) is cpu intensive. With that said, if you have to choose between a lot of RAM or a lot of CPU you should probably choose RAM in 9 times out of 10.



This is what is needed just to be able to boot the system - to run a serious service such as even a very small webpage you would need more system resources.


Didn't find your favourite operating system? Of course there are many other popular operating systems used for virtual servers. Unix-based and Linux based servers are most common and since many systems are based on Debian (such as Linux Mint, Ubuntu etc) it is usually a good idea to check the figures above. How ever it is always best to keep at least 30% margin.
8
We often get the question: "How much RAM do I need in my server" (or how many cpu cores or hard disk space for that matter).

Here's a quick guide and an absolute minimum recommended system requirement.

Always use more, especially with RAM you can never get "too much". At least keep a 30% margin, ie have 30% free RAM available for things that might happen (such as all your visitors decide to visit your webpage at the same time etc)!

Many operating system such as Ubuntu or Cent OS recommend a minimum. This is the minimum system resources needed to be able to boot the server. You will need more than this. For example Ubuntu recommends that in order to run 10.04 LTS you need no less than a 333Mhz CPU (!!!!) and 256MB RAM. Yes, your server would probably boot up with 256MB RAM but we always recommend that you use no less than 1GB per CPU Core (and no, we do not currently run any 333Mhz CPUs).

This is for an "idle" server, ie for a heavily loaded webserver you would most likely want to have more available system resources.


Many users prefer Cent OS 5 instead of 6 or Ubuntu 10.04 instead of 12.04 etc. This could be a way for you to "save some RAM". Ubuntu 10.04.4 LTS (32 or 64-bit version) typically runs smoother with less RAM than 12.04 LTS for example. In fact many system administrators prefer 10.04 LTS - which is also a supported Lont Term Support-version - since the end user experience might be a bit faster.

Still it is probably to start with 2GB RAM (at least 1GB per CPU core) and do some testing and then come back and order more RAM and probably some extra storage.

Conclusion: Ram needed would be: at least 1GB, but preferably 2GB per Core.

..So, how many CPU-cores do you need then? Why not start with two. Many servers run fine with as little as two cpu cores. How ever, with only one core your entire system "hangs on a single thread" - two cores is much better. For a busy server you would probably want at least 3 or 4.


Disk space?
10GB will get you a bootable system for almost all the major Linux distributions, ie you do not need more in order to get a system with all programs needed for the system - but you will not have very much space for storage.
If you are a noob: Why not add external storage for backups and start with only 10GB. You can easily add more internal storage or even separate "internal hard drives" later on when needed.

If you are not only looking on fireing up a vps to do some testing but are actually setting up a production server you might just as well add more internal storage right away. Are you running a webserver?`How much space do you need? do your webpages require each www-root to be 10GB for storage for all the content for your webpages such as images etc you should add more than 10GB per www-host - you do want to keep some backups right?
Oh, and yes - you do want to be able to do some up-/down-loading of development files?

Let's say your virtual webserver runs 5 webpages with 10B each:

Actual disk space needed now: 5x10GB

Backups, one backup per day for 7 days: 1x5x10x7 = 350GB

Lets say your typical websites need for storage grows with 10% per month and you want to keep log files for a month, you might just as well add an extra 15% right away.

Also, do not forget to configure an "alarm" to go off when your available disk space is less than 10%. We can help you set this up with SirV monitoring system.


Looking for a memory efficient server? Actually Cent OS tends to need a little more RAM, even when running in a virtual environment. Debian or Ubuntu might be a better choice for you if you need to use as little RAM as possible.

Also, remember that, contrary to Windows, a Linux server allocates all available RAM first and then starts to throw things out of RAM again - if your server has allocated all of its, let's say 8GB available RAM in total - this does not neccesarily mean that you are actually using all 8GB right now, you have been using 8GB since your last reboot but check with top or other system tools to see how much you are actively using right now. Probably less than 8GB. Are you using swap? Does the system 'feel' slow? maybe you do need more RAM but unless you are swapping something at all you might be just fine!
9
Niðavellir™ brandväggen / Köp Nidavellirbrandväggar direkt hos serverbutiken.se
« Last post by eco on February 09, 2013, 10:18:26 pm »
Du vet väl att du även kan handla din nidavellir firewall smidigt direkt på nätet via serverbutiken.com?
10
Generellt / Re: RAM-minne för "Egen Server" (tex Dedikerad Server)
« Last post by eco on February 08, 2013, 03:11:13 pm »
Hur gör man då för att tidigt upptäcka om något inte stämmer?

Jo, det är ganska enkelt men det kräver egentligen att du lägger lite tid då och då (eller tecknar något av våra IT-supportavtal och låter oss på compartment göra jobbet helt eller delvis tillsammans med er). Varje gång du loggar in kan (bör) du göra några enkla kontroller. Det går snabbt och är enkelt, här är några exempel:


Använder du operativsystemet 'compartment Linux' (http://linux.compartment.se) så kan du helt enkelt ange kommandot 'up' (du skriver helt enkelt bara: "up" direkt i prompten) och du får ett resultat tillbaks som visar lite hur systemet jobbar just nu, och den senaste tiden). Använder du någon annan version av Linux eller Unix kan du i regel använda kommandot uptime och top för att bilda dig en snabb överblick över hur servern "mår". Tänk på att dessa kommandon bara tittar på just nu, i regel de senaste femton minutrarna.

Ta därför också en titt på övervakningen, logga in på cc.compartment.se och rådfråga gärna vår supportpersonal om lite enkla tips och tricks.

Ser du att servern verkar jobba misstänkt mycket och du har svårt att förstå varför, ta gärna kontakt med oss och be oss logga in direkt i systemet, kanske är det något som faktiskt indikerar att du bör uppgradera, kanske är det ett program som "jobbar på fel sätt" och som kan åtgärdas enkelt.

Det vi inte alls tittat på i denna forumtråd är hur diskutrymmet används, dvs du kanske har väldigt ont om internt lagringsutrymme på hårdiskar i din server. Detta kan såklart också påverka vissa saker och du bör självfallet aldrig få helt fullt. Dessutom använder vissa program /tmp (eller /var/tmp osv) och här behöver du tex i regel ha lika mycket ledigt utrymme som dessa processer tar upp. Ska du tex komprimera en fil på 2GB så kanske ditt komprimeringsprogram behöver 2GB på /tmp tillgängligt under arbetets gång osv. tumregeln om 30% överkapacitet är tillämpbar även på lagringsutrymme. Tänk dock på att saker som säkerhetskopior ofta förbrukar oerhörda mängder lagringsutrymme. 30% kanske inte räcker.
Se även till så att du inte får med en säkerhetskopia i säkerhetskopian, det är inte ovanligt att vi får samtal från kunder som gör en "full backup" och får med den förra fulla backupen även i den nya backupen, det säger sig självt att om du gör några sådana backupper så kommer du ganska snabbt fylla upp hela disken och inte kunna packa upp någonting för att radera filer ens en gång.

Använd alltid någon av våra externa lagringstjänster för lagring av säkerhetskopior. Inte minst för att undvika saker som att någon av misstag råkar radera fel fil, det händer den bäste då och då och om din enda säkerhetskopia ligger lokalt så är det helt enkelt kört om du raderar den.

Något så enkelt som en 20GB backup-tjänst kan vara en livräddare i sådana situationer.
Pages: [1] 2 3 4