Planet Fedora

 

Iniciando un proyecto con MongoDB para la web, me vi en un camino donde no sabía que framework web utilizar, usar django era mucho para las características que necesitaba, yo no usaría su ORM asi que prácticamente dejo de usar medio framework. Por ende después de varios días, gracias a @flaper87 (http://blog.flaper87.org/), me incliné por Flask, descargue la documentación en PDF y en ePub (SI!), empece a leerla y de verdad es muy sencillo iniciar una aplicación web, sin tantos parámetros.

Flask

Es un framework web ligero basado en Werkzeug WSGI toolkit y Jinja2, por ende las plantillas son muy similar a las de Django (Me parece esto inteligente); Flask es llamado microframework, pero lo “micro” no lo tiene en ningún lado, es extensible, asi que se pueden usar extensiones que hacen la vida mas fácil.

La primera versión de Flask, vio luz el primero de abril de 2010, y desde entonces ha ganado popularidad.

Hola Mundo!

En la documentación y la pagina del proyecto muestra un sencillo ejemplo de Flask, el eviterno “Hola Mundo”.

1
2
3
4
5
6
7
8
9
from flask import Flask
app = Flask(__name__)
 
@app.route("/")
def hello():
    return "Hello World!"
 
if __name__ == "__main__":
    app.run() Documentación

Uno de los punto a favor de este framework es su documentación ordenada, y disponible en diferentes formatos para su descarga y posterior lectura.

La documentación se puede acceder a través de la siguiente dirección: http://flask.pocoo.org/docs/

Seguiré estudiando la doc, y escribiré nuevos artículos de este framework.

Depuis un certain temps (mars 2009), je maintiens à titre totalement officieux un paquet RPM du serveur IIPImage dans mon dépôt personnel.

J'ai récemment décidé de l'intégrer dans les dépôts officiels, le but de mon dépôt n'étant pas de fournir des paquets sur le long terme, mais davantage de me servir d'incubateur en quelque sorte.... J'ai donc soumis une revue sur le Bugzilla.

Grâce aux conseils toujours très avisés de Remi sur cette revue, j'ai fait évoluer le paquet, apportant certaines modifications qui ne sont pas dénuées d'intérêt :

• le paquet ne dépend plus de apache HTTPD, ceux d'entre vous qui utilisent d'autres serveurs web peuvent donc installer le paquet sans dépendances disons... farfelues
• une unité Systemd qui permet d'exécuter le serveur seul, sur un port spécifié. Le service n'est disponible que sous Fedora 18 actuellement.

Les paquets nécessaires sont disponibles via mon dépôt pour les versions 17 et 18 de Fedora, ainsi pour les versions 5 et 6 de RedHat (et équivalents). Une fois la revue menée à bien, les paquets seront disponibles sur les dépôts officiels et seront supprimés de mon dépôt personnel.

Si vous souhaitez utiliser Apache HTTPD et mod_fcgid avec le serveur IIP, installez dans un premier temps les paquets adéquats :

$ su -lc 'yum --enablerepo=trashy install iipsrv-httpd-fcgi'

Vous trouverez dans le dossier /etc/httpd/conf.d un fichier nommé iipsrv.conf, dont vous pouvez vous inspirer pour votre configuration spécifique. C'est à peu près aussi simple que ça ; votre serveur IIP est désormais installé. Pour vérifier son fonctionnement de base, rendez vous à l'adresse http://localhost/iipsrv (ou celle que vous aurez configurée) ; vous devriez voir une simple page avec le nom du logiciel, sa version, un lien vers son site web et le nom de l'auteur.

Il semble qu'il ne soit actuellement pas possible de fournir de façon correcte des fichiers de configuration pour les autres serveurs, aussi, si vous souhaitez utiliser le serveur IIP avec un autre serveur web, ou directement en tant que service, installez uniquement le paquet iiprsv ;

$ su -lc 'yum --enablerepo=trashy install iipsrv'

Référez-vous ensuite à la documentation du serveur IIP ainsi qu'à celle de votre serveur web pour paramétrer tout ça correctement.

Si vous souhaitez utiliser le service, notez que l'adresse IP et le port sont configurables via un fichier actuellement disponible dans /etc/iipsrv/iipsrv.conf, dont le contenu est le suivant :

IP=127.0.0.1 PORT=9002

Une fois les valeur adaptées, lancez le serveur comme vous en avez l'habitude :

$ su -lc 'systemctl start iipsrv'

Votre serveur IIP est en route !

Vous pourrez tester ça avec Apache 2.4 et mod_proxy sous Fedora 18, par exemple. Ajoutez à votre configuration la ligne suivante (en adaptant l'hôte et le port si vous avez modifié la configuration par défaut) :

ProxyPass /iipsrv fcgi://127.0.0.1:9002/

Relancez Apache, et le tour est joué. L'adresse http://localhost/iipsrv devrait vous renvoyer la page par défaut.

Notez que par défaut, SELinux ne permettra pas à Apache de se connecter à un port qu'il ne connait pas. Pour y remédier, il vous suffira d'avoir recours aux bons et loyaux services de semanage :

$ su -lc 'semanage port -a -t http_port_t -p tcp 9002'

Notez enfin que ce paquet n'est peut-être pas actuellement dans sa version finale (tant que la revue n'est pas terminée), les modifications ultérieures ne devraient cependant pas avoir trop d'impacts (j'aimerai en être absolument certain, mais ma boule de cristal est malencontreusement tombée par terre récemment, et refuse catégoriquement de fonctionner :p).

N'hésitez pas à participer à la revue, ainsi qu'au projet IIPImage !

Bitte beachten Sie auch die Anmerkungen zu den HowTos!
Das xfce4-termina (ehemals Terminal) verfügt aber Version 0.6 über einen Dropdown Modus. In diesem Modus kann das Terminal wie ein Dropdown-Fenster geöffnet werden.

Der größte Vorteil ist sicher, dass das Terminal in das Icon im Benachrichtigungsbereich minimiert werden kann und dort im Hintergrund weiterhin seinen Dienst verrichtet.

Um den Dropdown-Modus effektiv nutzen zu können, empfiehlt es sich, einen Tastatur-Shortcut zu definieren. Dazu öffnen wir die Tastatur-Einstellungen unter Einstellungen -> Tastatur und wechseln im sich öffnenden Fenster in das Register Tastaturkürzel für Anwendungen. Dort legen wir über hinzufügen einen neuen Tastatur-Shortcut an.

Als Befehl tragen wir

xfce4-terminal --drop-down

ein und vergeben nach dem Klick auf OK die gewünschte Tastenkombination. Anschließend können wir die Tastatur-Einstellungen über Schließen wieder verlassen und das xfce4-terminal über die von uns gewählte Tastenkombination im Dropdown-Modus nutzen.

Ich persönlich habe den Dropdown-Modus auf die F12-Taste gelegt.

I am a sysadmin for Computer Science House, recently we have been having some issues with our AC units. Since summer is here, and we are running a skeleton crew in Rochester I decided to try and make a monitoring system to keep track of how hot our servers are running. This way we can try and keep ahead of the game and predict what machines will be effected by thermal emergencies first. The first part of this project is called Heat. Heat is a small pure python library for grabbing information from a computers temperature sensors on linux. At this point Heat is really simple. It gives you access to the temperature in Celsius, Fahrenheit, and the sensors label. One of the neat things about heat is that it supports both python2 and python3. Check it out on github and pypi

The Wayback Machine reveals that 20May2004 was the first time it crawled http://planet-india.randomink.org/ It has been nine years of making friends, crowd-surfing, reading about stuff folks are up to, life hacks and so much more. There’s not much to say other than “keep writing!” I know of a number of folks who like what they read and help out by pointing out new feeds which need to be aggregated.

dnf, the experimental fork of yum was introduced in Fedora 18.  Under the hood, dnf uses the libsolv library from openSUSE (also used by Zypper) and aims for near 100% compatibility with yum.  Nearly all command line options are the same and instead of /etc/yum.conf, it uses /etc/dnf.conf but the configuration options are not changed. dnf is parallel installable along side yum (yum install dnf) and the plan (30:05) is to make it the new yum only by Fedora 22 so you have ample time to participate.

I have setup a bash alias (alias yum=’sudo dnf’ in ~.bashrc and source ~/.bashrc) in my system that pretends that dnf is yum so that I don’t have to throw away my muscle memory.  In the course of the last several months, I have filed over a dozen  bug reports and new feature requests (mostly to bring dnf in line with what yum already supports) and the core dnf (especially in Fedora 19) is usable (with the exception of one weird bug) and  the performance is much better compared to yum.  There are quite a few nice features missing however.  This includes support for Delta RPM,  history undo, parallel downloads,  auto-remove, bash completion and several group commands.

Try it out and report any bugs.

It's a pass on the RHCE exam, w00t w00t!

As you might heard, we at Fedora had FUDCons (Fedora Users and Developers conference), which is now replaced by a conference named Flock. The first one will be held in Charleston, South Carolina between Aug. 9th and 12th. 2013. Coming there is a unique chance this year, to meet many Fedora users and developers to come together, discuss new ideas, work to make those ideas a reality, and continue to promote the core values of the Fedora Community: Freedom, Friends, Features, and First.

OpenStack is a somehow complex thing to setup and to integrate into Linux distributions. Thus, I proposed an OpenStack testing hackfest at Flock, to test the latest build for Fedora, and also to bring users and developers together into one room. Currently, it is not decided, if this session is accepted, so please stay tuned.

The weather’s picking up so it’s time for spring cleaning around the house. When I moved back to Barcelona three years ago I took with me my old analogue photos and negatives, with the idea of sorting through them at some point and getting them digitized. And while I’m at it, maybe it’s time to pull all my various folders of photos together too and organize them.

Well, I finally started. I grouped the negatives, labeled them by year, put them in individual envelopes, and handed them off to a professional lab to scan them after doing a quick test run on one set (which turned out great, but it’s *really* annoying me that they scan to JPEG by default, charge 40% extra for TIFF, and use a non-multiple-of-8 resolution to scan at which means I can’t losslessly rotate the negatives. Yes, I’m anal.)

So now I pulled together all my various folders of photos, and before I start doing tagging and stuff like that, I want to organize them in a decent folder layout. Googling for ideas pretty much suggests that the way to go is

YYYY/MM/DD

with possibly some description together with the DD

I’m not really happy about that, however, because there are certain things I’d like to be able to do:

• easily see where photos come from – did I make them ? did I get them from someone ? Did I download them from Facebook ?
• Are these original files from a camera without editing ?
• Are these the original scans ? From negatives ? From actual photos ? Or are they retouched, rotated, denoised, …
• Are these photos SFW ? Can I point my media center slideshow to this directory and have it safely show any photos under it ? (What do you mean, you’ve never snowboarded at night in only your underwear, and mooning the photographer ?) Or maybe not even SFW, but simply watchable and reasonable quality or subject material?

I realize some of these issues can not be resolved simply with a directory layout. But I’m sure some of you must have had similar issues or come up with a slightly better layout ?

Point me in the right direction please.

හන්තාන පාසල් විද්‍යාගාර වැඩසටහන යටතේ නුවර එළිය දිස්ත්‍රික්කයේ වළපනේ අධයාපන කළාපයේ දුෂ්කර පාසලක් වන සාගල පුර විදුහලට පරිගණක පහකින් සහ අවශ්‍ය අනෙකුත් උපාංග වලින් සමන්විත පරිගණක විද්‍යාගාරයක් ලබා දීමේ ව්‍යාපෘතිය අපි දැනටමත් ආරම්භ කර ඇත.


මේ සඳහා ඇස්තමේන්තුගත මුදල රු. 260,000 වන අතර මේ වන විට රු. 80,000ක මුදලක් එක් රැස් කර ගැනීමට හැකි වී ඇත. එයින් රු. 52,000 ක මුදලින් එක් පරිගණයක් මිලදී ගැනීමේ කටයුතු මේ වන විටත් සිදු වෙමින් පවතින අතර නුදුරු අනාගතයේදී එම පරිගණකය සාගල පුර විදුහලේ සිසු දරු දැරියන්ගේ අධයාපනය කටයුතු වඩාත් හොඳින් කරගෙන යාමට සහය වීම සඳහා පාසල වෙත ලබා දීමට අපි බලාපොරොත්තු වෙමු. ඉතිරි පරිගණක හතර සහ අනෙකුත් උපාංග අප වෙත මුදල් ලැබෙන ආකාරය අනුව මිළදී ගෙන පාසල වෙත ලබා දීමට අපි බලාපොරොත්තු දෙමු.
තවද පරිගණක සියල්ල එකවර ලබා දිමෙන් තොරව  මුදල් සූදානම් වූ විගස අදාල පරිගණ ලබා දීම සිදු කරන බව කරුණුවානෙ සලකන්න. එනම් මීළඟ රු25,000 ලැබුණු විගස දෙවන පරිගණකයද ලබා දෙනු ඇත.
රු. 80,000ක මුදල එක් රැස් කර ගැනීම සඳහා මූල්‍යමය දායකත්වය සැපයූ පුද්ගලයින්ගේ නම් පහත සඳහන් වේ.

• හර්ෂණ වීරසිංහ
• ජීවන් සූරිය ආරච්චි
• බන්දුල රණතුංග
• තිස්ස දොඩංගොඩ
• රෝහණ දිසානායක
• අසංග අමරවංශ
• සිසි කැළුම්
• ලක්ෂාන් පෙරේරා
• ප්‍රවීන් ඉන්ද්‍රණාම
• කල්ප පැතුම්
• ඩනිෂ්ක නවීන්

මෙම වයාපෘතියේ සාර්තකත්වයට මූල්‍යමය මෙන්ම ප්‍රචාරණයෙන් සහයෝගය දැක්වූ ඔබ සැමට අපගේ අවංක ස්තුතිය පිරිනමමු. ඔබගේ සියළු සහයෝගයන් අනාගත පරපුරේ නැණ පහන් දැල්වීම සඳහාම වනු ඇත.
මෙම පාසලයේ දරුවන් සහ ගුරුවරුන් සඳහා පරිගණක භාවිත කිරීමට අවශ්‍ය මූලික දැණුම ලබා දිමේ පුහුණු වැඩ සටහනක්  ක්‍රියාත්මක කිරීමට නියමිත බැවින්. මේ සඳහා දායක වීමට කැමති අය වෙතොත් අප වෙත දන්වන්න.
 -------------------------------------------------------------------------------------------------------------

ඔබටත් දායක වීමට හැකියාවක් ඇත්නම් පහත සඳහන් වන ඒකා බද්ධ ගිණුමට (Joint Account) ඔබේ මුදල් බැර කර අදාල රිස්ට්පතේ පිටපතක් බන්දුල රණතුංග මහතාට හෝ කල්ප පැතුම් සොයුරාට ලැබීමට සලස්වන්න.

මුදල් ලබා දිමෙන් අනතුරුව බන්දුල මහතාට හෝ කල්ප සොයුරාට අදාල රිසිට්පතේ පිටපත සමඟ ඔබේ නම, අදාල මුදල, දුරකතන අංකය සහ විද්‍යුත් පැතැල් ලිපිනය හෝ සාමාන්‍ය තැපැල් ලිපිනය දන්වන්න.

ගිණුම් අංකය: 8480050534
බැංකුව: කොමර්ෂල් බැංකුව, යුනියන් පෙදෙස.
ගිණුම් හිමියන්: බන්දුල පුෂ්පකුමාර රණතුංග හෝ වැලිවිටිගොඩ හේවගෙ කල්ප පැතුම්
ගිණුම් වර්ගය: ඒකා බද්ධ


COMMERCIAL BANK, UNION PLACEACC NO: 8480050534ACCOUNT HOLDERSMR BANDULA PUSHPAKUMARA RANATUNGAORMR WELIVITIGODA HEWAGE KALPA PATHUM


මූල්‍යමය දායකත්වන් සඳහා බන්දුල රණතුංග මහතාව අමතන්න:
ජංගම දුරකතන අංකය: 0714315426
විද්‍යුත් තැපෑල: bandula.ranathunga {[AT] } gmail {[DOT]} com
කල්ප පැතුම්:   callkalpa {[AT] } gmail {[DOT]} com 

පරිගණක උපාංග සහ ඒ ආශ්‍රීත තාක්ෂණික තොරතුරු සඳහා අතුල හේරත් මහතාව අමතන්න:
ජංගම දුරකතන අංකය:  0718217443

Melanjutkan tulisan sebelumnya.

Setelah selesai memasang dan mengkonfigurasi Func, kini saatnya kita coba memakainya.

Saat pertama kali funcd (func daemon) berjalan di minion, dia akan menghubungi certmaster. Kalau sertifikat miliknya belum terdaftar di certmaster maka ia akan automagicly mengajukan permintaan persetujuan.
Yang harus kita lakukan adalah menyetujui permintaan ini di certmaster, yaitu dengan cara menandatangani sertifikat milik minion tersebut.
Jalankan perintah certmaster-ca -l di komputer overload/certmaster untuk melihat daftar permohonan sertifikat.

1
2
[dheche@puppet ~]$ sudo certmaster-ca -l
dheche-laptop.ip

Dari contoh di atas terlihat ada permintaan persetujuan sertifikat untuk dheche-laptop.ip. Kemudian tandatangani sertifikat tersebut.

1
2
sudo certmaster-ca -s dheche-laptop.ip
/var/lib/certmaster/certmaster/csrs/dheche-laptop.ip.csr signed - cert located at /var/lib/certmaster/certmaster/certs/dheche-laptop.ip.cert

Setelah penandatanganan sertifikat, baru kita dapat mengirimkan perintah ke minion-minion yang sertifikatnya sudah ditandatangani.

Coba kita lihat dulu daftar sertifikat sudah ditandangani

1
sudo certmaster-ca --list-signed

Kemudian coba lihat daftar minion yg terdaftar

1
sudo func '*' list_minions

Perhatikan struktur baris perintah tersebut …

1
func [target] [command]

target: bisa kita isi ‘*’ untuk memerintahkan semua minion, atau ‘nama_minion’ untuk memerintahkan spesifik ke minion tertentu. kita juga bisa menggunakan pola tertentu, mis: ‘db*.com’ dsb
command: perintah yang bisa jalankan, antara lain: list_minions, call, show

Sebelum lanjut, kita perlu tahu dulu perintah apa saja sih yg bisa kita kirimkan ke minion? Kita bisa memanfaatkan perintah call untuk memanggil module remote yang ada di minion

1
sudo func '*' call system list_modules

Sekarang kita coba panggil salah satu module untuk melihat method apa yg tersedia. Misalnya kita panggil module command

1
sudo func '*' call command list_methods

Kita coba jalankan salah satu method yg tersedia

1
sudo func '*' call command run 'uname -r'

Sudah ada bayangan ? Coba kita main-main dengan modul-modul lainnya, misalnya modul yumcmd

1
sudo func '*' call yumcmd 'check_update'

Gampang kan ? Func ini keren kalau digabung dengan beberapa tools lainnya, misalnya puppet dan cobbler.
Selamat mencoba.

After hearing about Android Studio via Google I/O 2013, I have been toying around with underlying software called  IntelliJ IDEA Community Edition which is a pretty sweet free and open source (Apache v2 licensed)  IDE. IDEA was for packaged for a while in Fedora but has been retired unfortunately. Oddly no other linux distribution seems to be packaging it either. So I was trying to figure out how much work it is to revive it. Fedora git still has the old spec files and patches as part of its history. fedpkg clone intellij-idea and figure out the last useful git commit before it was retired via git log and make git point to that via git reset –hard e366b11. Clone the upstream git repo for IDEA and do a quick and dirty build and bingo!

Well… not quite.  Fixing the spec and associated patches etc  to build the latest version and follow the Fedora packaging guidelines would take a lot more work but one of the things that was bugging me was something that started out as a trivial thing yet turned to be a surprising problem.  The icon shown in alt+tab window was blurry. Looked around for a high resolution variant of the same icon and shoved it into hicolor icon theme directory and ran gtk-update-icon-cache only to realize that the GNOME Shell overview is showing a different icon from the one in alt+tab. Head over #fedora-desktop channel and talked to Matthias Clasen, adamw and Kalev and fiddled with a few different settings and still no go.

Read up on how GNOME Shell does the window matching and realize that this is a long standing problem with Java applications. Java sets the WM_CLASS based on the name of the class running the Swing main loop and there is no real Java API to reset it and since many applications can have the same classname, this confuses several desktop environments and window managers. A bug report has been open since early 2007 and I have filed one against Fedora openJDK in addition to the one on poor font rendering, hoping to see some progress on these issues.  Some folks have even developed elaborate hacks to fix the problem but atleast for GNOME Shell, all it took was to run sleep 5; xprop | grep WM_CLASS | awk ‘{print $4}’ and click on the IDEA window which reveals the class name as “jetbrains-idea”. If you rename the desktop file to match the classname (jetbrains-idea.desktop), GNOME Shell is able to pick up the right icon specified in the desktop file regardless of what the name or generic name is.  One can set the latter two to something appropriate like IntelliJ IDEA and GNOME Shell overview and alt+tab window would show that instead. Funky!

With much help from Scott Olson, I’ve packaged Chicken Scheme for Fedora (and EPEL 6).

Chicken is a Scheme to C compiler that implements the R5RS Scheme language standard. It is portable and runs on x86, x86-64, IA-64, PowerPC, SPARC and UltraSPARC, Alpha, MIPS, ARM and S/390, according to their front page.

Please report any packaging bugs you come across, and we’ll try to get them fixed up.

I’ll outline some of the process for getting it into Fedora below.

Because Chicken distributes its releases as generated C code, and not the Scheme code used to make them, the Fedora Packaging Committee asked me to go through the process of bootstrapping Chicken.

After much discussion with Toshio Kuratomi, I finally understood that the process for bootstrapping a package means that you build it once, as given (with the C sources), then request a Buildroot Override in Bodhi. Once you do that, you wait up to 20 minutes for it to activate, then go compile the original (Scheme, in this case) sources, using the buildroot override’d compiler.

The process looked like this:

• Decide I want to package.
• Ask if I need to bootstrap, and get told that it’s iffy[1], but it would probably be a good idea to do it.
• Write a spec file, with a toggleable %bootstrap flag. This lets us describe the process for building with, and without, the bootstrap available, in the RPM spec file. Building once the buildroot override is active is just a matter of toggling the flag, incrementing the release, and adding a changelog entry.
• Get the package approved.
• Build the package in Koji for all branches. (fedpkg build)
  • For the master (rawhide) branch, toggle the bootstrap flag, and increment release, then build again. Rawhide was done after that.
  • For the other branches, do fedpkg build as normal, but don’t do fedpkg update yet. Once the fedpkg build completes, go request a buildroot override.
  • Add the NVR of the fedpkg builds you did above to the buildroot.
  • Wait 20 minutes for the buildroots to generate.
    • It’s worth noting that you don’t need to do anything else to get the buildroot override active. All buildroot overrides are global to all builds.
  • Merge the latest commit from master into each of the branches (where we toggled the bootstrap flag and incremented Release).
  • fedpkg build
  • fedpkg update

Quite a number of steps, but they all make sense once you understand the process.

Once this was done, I convinced Scott to get a FAS account, and got him proxy-sponsored into the packaging group so that he could help maintain the package, since he was a huge help in getting it packaged up.

Enjoy using the package!

This is another tutorial about OpenGL.

The main goal it's : using GLFW library.

It's very simple to use this library.

If you want to read more the go to this website.

Hey folks,
Working on something for Spot I revived some code I had written a
few years ago and then discovered that other people had made much more
robust leveled topological sorts than I had written

Anyway – if you grab the files from:

http://skvidal.fedorapeople.org/misc/buildorder/

And run:

python buildorder.py /path/to/*.src.rpm

it will look up the interdependencies of the src.rpm to figure out a
build order. It outputs a bunch of different things:
1. a flat build order
2. a build order broken out by groups – you can build all the pkgs in
any group in parallel provided that all the pkgs in the previous group
have finished building.
3. outputs lists of direct loops between srpms.
4. probably will output A LOT of noise and garbage from the rpm
specfile parsing from the rpm.spec() module

But it might be worth a look at and, ideally, patches to make it a bit
more robust.

If you have a set of pkgs which you need to build but you can’t figure
out the buildorder this might help you out.

I’d love to know how often it is right or ‘right enough’.

Known Issues:
1. some spec files make the rpm.spec() parsing break in interesting
ways – sometimes tracing back
2. if a pkg is not dependent on any other pkg and nothing else depends
on it – they get lumped in the last grouping. Not really an issue -
just something someone noticed and was surprised.
3. It will handle file-buildreqs not at all, it will handle virtual
provide buildreqs, not at all, if your buildreqs are REALLY picky about
requiring <= Version – it will ignore all of that.
4. I fully expect that 2 or more level circular build deps (foo req bar
req baz req quux) will not be detected but will make the topological
sort function die). If so…. tough… go fix your packaging.

Anyway – give it a run and see if it helps you solve a problem.

If it does let me know about it. Some of us are curious if this could
fit well in mockchain or wrapped around/in mockchain.

Put it in your calendars .. May 28th is Fedora 19 virtualization test day.

New features include nested virtualization on Intel, new Boxes, new libosinfo, new qemu, KMS-based spice driver, live storage migration and virtio RNG.

Every day is libguestfs test day. Just follow the instructions here.

This week we took a patch from Harald Hoyer to the Rawhide kernel.spec to switch to using the kernel-install tool to install the kernel onto the system. This new tool is provided by systemd and is intended to be distribution agnostic, with the eventual goal of getting into the upstream kernel Makefile as well.

Previously, the Fedora kernel package would call a script called 'new-kernel-pkg' to do the boot loader configuration addition, initramfs creation, and depmod steps in the RPM %posttrans script. That script is provided by the grubby package, which despite its name doesn't mean it only works with grub. It works with grub, grub2, silo, yaboot, lilo, and a variety of other bootloaders. However, to the best of my knowledge, it is a Fedora specific package. The other distributions all use their own flavor of initramfs/bootloader tooling for one reason or another.

The kernel-install tool provided by systemd is aiming to replace all of those tools. It was created in part to support the Boot Loader Spec, which aims to create a cross-distro way of managing boot loaders and boot loader entries. The intention is to make dual/multi-distro booting work well without requiring a lot of manual hacks or configuration. If you have questions on this, I would encourage you to talk to Harald Hoyer or Kay Sievers as they're driving that work.

At the moment, Fedora's kernel-install is patched to still call new-kernel-pkg if it exists. That should easy the transition for existing installs and result in machines still working. About the only fallout should be that you won't be able to install Rawhide kernels on older releases of Fedora. The RPM requirements specify that you have systemd >= 203 and dracut >= 027. Of course, there still may be bugs. If you're running Rawhide and hitting issues when you install or remove kernels, let us know.

Udah lama gak main-main dengan tools untuk maintain server. Kebetulan seminggu ini lagi iseng nyobain banyak hal remeh-temeh gak penting.

Mainan yang pertama, Func (Fedora Unified Network Controller). Ini tools untuk menjalankan suatu perintah ke banyak mesin sekaligus. Dulu udah pernah nyoba sih, sekarang cuma pengen revisit aja, pengen tau ada perkembangan apa. Kebetulan juga saya sudah lama gak jadi sysadmin, jadi itung-itung ini nostalgia … hahahaha

Secara umum, yang kita perlukan setidaknya ada 2 komputer. Komputer pertama berfungsi sebagai Overload (komputer tempat kita menjalankan perintah) dan komputer kedua berfungsi sebagai Minion (komputer yang menerima perintah dari overload).

Yang kita perlukan di Overload adalah Certmaster dan Func. Certmaster ini adalah daemon yang berfungsi untuk menangani sertifikat (semua komunikasi antara overload dan minion dilakukan secara terenkripsi). Sebenarnya certmaster bisa saja dipasang terpisah dari funcd (daemon func), tapi supaya lebih sederhana, saya gabung saja ya.

Sedangkan di Minion, kita hanya perlu func saja.

OVERLOAD

Proses instalasinya sederhana, tinggal yum install func

1
sudo yum install func

yum akan secara automagicly ikut menginstal certmaster

Selanjutnya, konfigurasi di Overload. Sunting berkas /etc/certmaster/minion.conf

1
2
3
4
5
[main]
certmaster = certmaster.ip
certmaster_port = 51235
log_level = DEBUG
cert_dir = /etc/pki/certmaster

Perhatikan baris kedua, isikan dengan hostname server overload. Sesuaikan dengan data DNS atau kalau tidak mau repot-repot, cukup catatkan saja pasangan hostname dan ip di /etc/hosts.
Secara bawaan, certmaster akan memakai port 51235.

Kemudian sunting berkas /etc/func/minion.conf

1
2
3
4
5
6
7
8
[main]
log_level = INFO
acl_dir = /etc/func/minion-acl.d

listen_addr =
listen_port = 51234
minion_name = certmaster.ip
method_log_dir = /var/log/func/methods/

Yang perlu diperhatikan cuma di baris ke tujuh (minion_name), isikan dengan hostname komputer overload.

Izinkan port-port ini di firewall, sunting berkas /etc/sysconfig/iptables

1
2
-A INPUT -m state --state NEW -m tcp -p tcp --dport 51234 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 51235 -j ACCEPT

restart iptables

1
sudo service iptables restart

Kemudian jalankan funcd dan certmaster, serta pastikan ia aktif saat komputer direstart

1
2
3
4
sudo service funcd start
sudo service certmaster start
sudo chkconfig funcd on
sudo chkconfig certmaster on MINION

Selanjutnya kita pasang func dan konfigurasi komputer minion.

1
sudo yum install func

Sunting berkas /etc/certmaster/minion.conf

1
2
3
4
5
[main]
certmaster = certmaster.ip
certmaster_port = 51235
log_level = DEBUG
cert_dir = /etc/pki/certmaster

Perhatikan baris kedua, isikan dengan hostname server overload.

Kemudian sunting berkas /etc/func/minion.conf

1
2
3
4
5
6
7
8
[main]
log_level = INFO
acl_dir = /etc/func/minion-acl.d

listen_addr =
listen_port = 51234
minion_name = server-web.ip
method_log_dir = /var/log/func/methods/

Yang perlu diperhatikan cuma di baris ke tujuh (minion_name), kali ini isikan dengan hostname komputer minion.
Sebenarnya kita bisa mengosongkan variabel minion_name ini, nanti si certmaster akan automagicly memilihkan nama host yang sesuai, tapi di beberapa kasus saya lebih suka mendefinisikan nama minion ini secara manual, karena kadang kala komputer minion ini memiliki lebih dari 1 ip dan lebih dari 1 nama host, jadi lebih baik didefinisikan manual supaya lebih teratur.

Izinkan port 51234 di firewall, sunting berkas /etc/sysconfig/iptables

1
-A INPUT -m state --state NEW -m tcp -p tcp --dport 51234 -j ACCEPT

restart iptables

1
sudo service iptables restart

Jalankan funcd dan pastikan ia automagicly aktif saat komputer direstart

1
2
sudo service funcd start
sudo chkconfig funcd on

OK, proses instalasi dan konfigurasi Func sudah selesai.
Selanjutnya tinggal cara memakainya, tunggu di tulisan berikutnya.

Saat saya menggunakan driver nouvue untuk kartu grafis Nvidia yang ada di laptop, tanpa perlu setting ini itu bisa menampilkan splash boot dalam mode grafis dengan mulus. Tapi setelah menginstal driver proprietary dari nvidia, saat boot plymouth hanya menampilkan mode teks.

Solusinya sederhana, dari menu grub, tekan “c” (tanpa tanda petik ya) untuk masuk ke console.

1
2
3
set pager=1
insmod vbe
vbeinfo

Kemudian cari mode vga yang didukung dari daftar yg ditampilkan. Laptop saya mendukung resolusi 1360x768x32 (catat resolusi ini)

Kemudian pilih font yang diinginkan, misalnya saya memilih menggunakan font DejaVuSansMono, jalankan perintah grub2-mkfont seperti berikut:

1
sudo grub2-mkfont --output=/boot/grub2/DejaVuSansMono.pf2 --size=24 /usr/share/fonts/dejavu/DejaVuSansMono.ttf

Kemudian sunting berkas /etc/default/grub, sesuaikan dengan resolusi dan font yang diinginkan

1
2
3
4
GRUB_VIDEO_BACKEND="vbe"
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_FONT_PATH="/boot/grub2/DejaVuSansMono.pf2"
GRUB_GFXMODE="1360x768x32"

Langkah terakhir, backup berkas grub.cfg dan buat baru

1
2
sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bkp
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Restart komputer … selamat menikmati kembali tampilan splash mode grafis yang hilang

During my talks, I often try to make the point that horizontally scalable systems are often necessary not only to achieve high aggregate performance but also to overcome performance variation. This is true in general, but especially in a public cloud. In that environment, performance variation both between nodes and over time is much greater than in a typical bare-metal environment, and there’s very little you can do about it at the single-system level, so you pretty much have to deal with it at the distributed-system level. I’ve been using a graph that kind of illustrates that point, but it has a few deficiencies – it’s second-hand observation, it’s kind of old, and it’s for network performance whereas I usually care more about disk performance. To illustrate my point even more clearly, I took some measurements of my own recently and created some new graphs. Along the way, I found several other things that might be of interest to my readers.

The methodology here was deliberately simple. I’d get on a node, do whatever disk/volume setup was necessary, and then run a very simple iozone test over and over – eight threads, each doing random 4KB synchronous writes. I then repeated this exercise across three providers. It’s worth noting that each test is on a single machine at a single time. The variation across a broader sample is likely to be even greater, but these samples are already more than sufficient to make my point. Let’s look at the first graph, for a High I/O (hi1.4xlarge) instance.

Ouch. From peaks over 16K down to barely 6K, with barely any correlation between successive samples. That’s ugly. To be fair, Amazon’s result was the worst of the three, and that’s fairly typical. I also tested a Rackspace 30GB instance, and the measly little VR1G instance (yes, that’s 1GB) that runs this website at Host Virtual. The results were pretty amusing. To see how amusing, let’s look at the same figures in a different way.

This time, we’re looking at the number of samples that were “X or better” for any given performance level. This is a left/right mirror image of the more common “X or worse” kind of graph, which might seem a bit strange to some people. I did it this way deliberately so that “high to the right” is better, which I think is more intuitive. Too bad I don’t have comments so you can complain. :-P The way to interpret this graph is to keep in mind that the line always falls. The question is how far and how fast it falls. Let’s consider the three lines from lowest (overall to highest).

• The Rackspace line is low, but it’s very flat. That’s good. 97% of the samples are in a range from just under 6000 to a bit more under 4000. That’s pretty easy to plan for, as we’ll discuss in a moment.
• The Amazon line is awful. It has the highest peak on the left, but drops off continuously and sits below the HV line most of the time. As we’ve already noted, the range is also quite large. A flat line across a large range is exactly the opposite of a flat line across a small range; it’s very hard to plan around.
• The Host Virtual line is the most interesting. 70% of the time it’s very nice and flat, from 13.5K down to 12K, but then it falls off dramatically. Is this a good or bad result? It requires a bit more complex mental model than a flat line, but once you’re used to the model it’s actually better for planning purposes.

Before I describe how to use this information for planning a deployment, let’s talk a bit about prices. That VR1G costs $20 a month. The Rackspace instance would cost $878 and the Amazon instance would cost $2562 (less with spot/reserved pricing). Pricing isn’t really my point here, but a 128x difference does give one pause. When the effect of variation on deployment size is considered, those numbers only get worse. Even when one considers the benefits of Amazon’s network (some day I’ll write about that because it’s so much better than everyone else’s that I think it’s the real reason to go there) and services and so on, any serious user would have to consider which workloads should be placed where. But I digress. On with the show.

Let’s look now at how to use this information to provision an entire system. Say that we want to get to 100K aggregate IOPS. How many instances it would take to get there assuming the absolute best case, and how many it would take to achieve a 99% probability based on these distributions?

<style type="text/css"> table { margin-left: 1cm; } td { text-align: right; } </style> Provider Best Case 99% Chance Ratio Amazon 7 13 1.86 Rackspace 14 28 2.00 Host Virtual 8 11 1.38

Here we see something very interesting – the key point of this entire article, in my opinion. Even though Amazon is potentially capable of satisfying our 100K IOPS requirement with fewer instances than Host Virtual, once we take variation into account it requires more to get an actual guarantee. Instead of provisioning 38% more than the minimum, we need to need to provision 86% extra. As Jeff Dean points out in his excellent Tail At Scale article, variation in latency (or in our case throughput) is a critical factor in real-world systems; driving it down should be a goal for systems and systems-software implementors.

Before closing, I should explain a bit about how I arrived at these figures. Such figures can only be approximations of one sort or another, because the number of possibilities that must be considered to arrive at a precise answer is samples^nodes. Even at only 100 samples and 10 nodes, we’d be dealing with 10^20 possibilities. Monte Carlo would be one way to arrive at an estimate. Another way would be to divide the sorted samples into buckets, collapse the numbers within each bucket to a single number (e.g. average or minimum), then treat the results as a smaller number of samples. You can even use enumeration within a bucket as well as between buckets, and even do so recursively (which is in fact what I did). When there’s a nice “knee” in the curve, you can do something even simpler. Just eyeball a number above the knee and a number below, then work out the possibilities using those numbers and probability equal to the percentile at which the knee occurs. Whichever approach you use, you can do more work to get more accurate results but (except for Monte Carlo option) the numbers tend to converge very quickly so you’d probably be overthinking it.

OK, so what have we learned here? First, we’ve learned that I/O performance in the cloud is highly variable. Second, we’ve learned a couple of ways to visualize that variation and see the different patterns that it takes for each provider. Third, we’ve learned that consistency might actually matter more than raw performance if you’re trying to provision for a specific performance level. Fourth and last, we’ve learned a few ways to reason about that variation, and use repeated performance measurements to make a provisioning estimate that’s more accurate than if we just used an average or median. I hope this shows why average, median, or even 99th percentile is just not a good way to think about performance. You need to look at the whole curve to get the real story.