Search This Blog

Monday, November 30, 2009

איך לעבוד בעברית עם writer של libreoffice?

אז איך עובדים בעברית עם writer של libreoffice?

אחרי תקופה ארוכה של שימוש לינוקסאי באנגלית, אני שוב בנסיון להפוך את לינוקס לדסקטופ העיקרי ולהתנתק מחלונות (לא אופטימי במיוחד בעניין... יותר מדי נקודות ממשק חלונאיות בסוגיות שעדיין אינן מקבלות פתרון טוב דיו בלינוקס).

כך מצאתי את עצמי מחפש ומחפש  איך מיישרים לימין.

אז כדי לחסוך לעצמי ולאחרים את החוויה העתידית המתסכלת הזו, תיעוד קצר:

הכי פשוט:
בתפריט לך אל - Tools>Options>Language Settings>Languages
שם סמן את CTL (שזה אומר Complex Text Layout)
והחיים בעברית יהיו הרבה יותר פשוטים.

קישורים נוספים שיכולים להיות מועילים




Friday, November 20, 2009

how to tell in linux if your hardware is 32 bit or 64 bit ?

How to find out in  linux if my mahine is 64bit or 32bit ? 

To check the software, any one of the following commands will do
  1. uname -a 
  2. uname -m (more specific to the data you need) 
  3. arch (equivalent to 2) 
  4. file /sbin/init
  5. getconf LONG_BIT
To check the hardware, one of the following can do the trick: 
  1. cat /proc/cpuinfo
    the output is long 
    what we seek is the flags part, in which we seek for the lm flag. 
    lm=long mode 
    (long mode - https://en.wikipedia.org/wiki/Long_mode)

  2. sudo dmidecode -t processor
    the output is not too short;
    search for the characteristics; you should see "64-bit capable"

    btw, you can also use dmidecode to get  the "Version" and search the specifications on the internet

pay attention
over the years, I ran into some reports and claims on the net that neither of the commands to find out about the hardware were accurate (in some hardware cases), and that therefore, 
if you want to be 100% sure that the hardware is capable of running a 64 bit linux software, you need to run a boot cd/dvd with a 64bit linux. 
personally, i haven't encountered a case in which the dmidecode command failed me. 

Sunday, November 15, 2009

איך יודעים אם במחשב פועלת גירסת 32 סיביות או גירסת 64 סיביות של מערכת-ההפעלה חלונות ?

בחלונות XP -
לחץ על התחל, בחר הפעלה
 הקלד "control sysdm.cpl"  (אין צורך במרכאות בהקלדה האמיתית)
וראה מה כתוב תחת "מערכת" (אם מערכת ההפעלה היא 64 ביט, זה יהיה כתוב שם מפורשות. אם לא כתוב - המערכת היא 32 ביט).

בחלונות 7 -
לחץ על מקשי WIN+R (או לחץ התחל ובתיבת "התחל חיפוש" הקלד Run ובחר)
הקלד "control /name microsoft.system"(אין צורך במרכאות בהקלדה האמיתית)
וראה מה כתוב בחלק השני של המידע (system) ליד System Type



עודכן/נבדק לאחרונה: דצמבר 2012.

Monday, November 2, 2009

File not found (WFMLRSVCApp.ear) during Oracle 11g release 2 installation

A friend called yesterday evening, sad and worried. He was trying to install the new Oracle Database - 11g Release 2 - but got stuck. He kept getting the a "File not found" error during installation, and couldn't find where did he go wrong.



He followed me through his steps - He downloaded the installation zip files. He verified that they downloaded ok. He unzipped each one into a designated folder. Then he  followed all the pre-installation prerequisites like a good DBA. And yet, that horrible error message kept appearing, and he could find no where online why this happened to him....

Between the lines I could understand that the best part of his Saturday has been spent in repeating attempts to find why WFMLRSVCApp.ear was missing.

As I've had this dubious experience myself in the past, the solution was easy. In the past, Oracle installations that spanned several CD-ROMs were asking during installation for the next CD. During the passage to the age of downloading it all from the web things changed. Although the instructions on Oracle's website clearly state: "Download and unzip both files to the same directory" they are sometimes missed.

All he had to do was move all the files under \file-number-2-extraction-folder\database\stage\Components into the parallel ..\database\stage\Components underneath the first zip extraction folder, re-run the installation (after wiping away the left-overs from his failed installations) and the installation worked smoothly. 

Friday, October 16, 2009

Virtualization and Backup in the development environment - some thoughts

Virtualization shakes up Backup strategies! read the computer world article I ran into. I found it as I was searching to find what is new in the backup of virtual machines. Backuo of virtual machines is an issue I've been bothered with, ever since I made my first steps into virtualization, a couple of years ago. (Yes, I know that Mainframe guys have been tackling these issues for decades, in their own ways. But for a windows/linux guy such as myself, virtualization as an everyday practice is something relatively new. About three years as something to be aware with, and about a year and a half as something which is actually used in my technical life). 

Say what you say about virtualization, once you get used to it, like any paradigm-changing technology, it pops up everywhere.

And one of the main problems with these mushrooms-after-the-rain technology expansions is that infrastructure issues are frequently neglected, and my own experience teaches me that backup is the most popular subject to be put aside, for later. Backup is the ultimate winner of neglection, the poster boy of the not-urgent-enough, and the single most important action a sys admin can pre-emptively promote to save the day. 

Looking back at my own career I'm surprised at the number of incidents when I was the one to raise the questions of "how are backups done" about a server or a project, only to discover that this was an issue people never got to deal with. 

Over the years, whenever backup routines I've initiated or promoted were tested, under real life crashes and data disasters, those routines proved to be reliable, and enabled a swift return to work. But dream as you might about the appreciation you get after a crash well handled, you must tackle the frustrating efforts of promoting backup before the crash, dealing with servers that are frequently falling between departments or perceived as something not critical enough (it is just for development, no? I remember a manager asking me about a Unix db machine that served several development teams which has never been backed up since it was setup). 

Worse, you might have brought everything under your responsibility to a perfect backuping state, even including the routine restore mechanisms. But that was yesterday, and virtualization brings new machines into play, some of which you might not even think about when servers come to your mind, and it forces one to look forward, even if this means abandoning old techniques and developing new approaches. 

Of the key issues about virtualization is the ease of restoring a whole machine, In development environments, my own specialty, this creates a huge advantage - you can run a nightly backup creating a full snapshot, and assuming you are equipped to recover quickly from a hardware disaster, the time it will take to return to business as usual, is the time it will take you to rebuild the host. If you really care about such things, you will have more than one host to begin with, and thus, assuming you work with shared storage, the return to business time can be as short as the time it takes to import the backed up image of the machine into the other host. 

But such full backup schemes must not be adopted without other key issues handled. A good backup strategy must answer granular needs. The most common of which is that need to restore a single element. That file the was deleted or changed several weeks ago and was found now to be needed as it once was. If we rely only on full snapshots, the restore time may create some troubles, especially in environments where the existence of two identical virtual machine creates problems. Solutions can be found, some more elegant than others and the problem intensifies when we are not talking about file-system restore issues but on databases that reside within virtual machines. A this stage, the importance of exporting the database on a nightly basis may be found. Such a solution is naturally suitable only for small to medium size databases. As the information revolution is created larger and larger data schemes, we see that development environments too  are growing in size, bringing complications previously known mainly in production environments, to the table of the development environment's specialist. 

And yet, as complicated as life may become, we must not forget the simplest questions: 
1. if tomorrow a hardware failure strikes, can we return with ease to a working formation? 
2. if the answer to question 1 is "no", what does it mean ? (how complicated will the effort be? how much data will be lost? how tolerant is our organization to a situation of a lost development server that cannot be restored? ) 

and to put it in managerial terms - what is the cost/benefit of postponing the creation of a backup solution for our virtual machines, in comparison with the cost/benefit of possible solutions? 
(when this question is asked, the assumption that there will be a fault at a certain point in the not too distant future is essential. do not accept any other. don't forget to propose the possibility of a disk crash on the eve before a deadline.) 

Monday, September 21, 2009

איך לקנפג עליה אוטומטית של לאמפ בלינוקס

1. ניצור בתור root סקריפט ב
/etc/init.d
שישרת עליה והורדה (כלומר שיקבל פרמטר של start או של stop).
(כללנו גם כמה פרמטרים אחרים למען הנוחות. )

זה הסקריפט :

#!/bin/bash
# See how we were called.
case "$1" in
    start)
        /opt/lampp/lampp start
        RETVAL=$?
        ;;
    stop)
        /opt/lampp/lampp stop
         RETVAL=$?
        ;;
    status)
        /opt/lampp/lampp status
         RETVAL=$?
        ;;
    restart)
        /opt/lampp/lampp restart
         RETVAL=$?
        ;;
    reload)
        /opt/lampp/lampp reload
         RETVAL=$?
        ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|reload}"
        RETVAL=1
        ;;
esac
exit $RETVAL

2. כשאנחנו שומרים אותו, נקרא לו lampp למען הנוחות. 

3. נשנה את ההרשאות ל755 - 
chmod 755 ./lampp

4. ניצור לינקים בספריות -
/etc/rc.d/rc5.d
  (לעלייה)
/etc/rc.d/rc0.d
  (להורדה)

למשל:
cd /etc/rc.d/rc0.d
ln -s /etc/init.d/lampp K99lampp

cd /etc/rc.d/rc5.d
ln -s /etc/init.d/lampp S99lampp

ועכשיו הזמן לבדוק שהכל אכן עובד....
(תזכורת: אם מדובר במכונה שמשרתת משתמשים אחרים, זה לא רעיון טוב לעשות reboot באמצע היום רק כדי לוודא את זה. מצד שני, אם מדובר במכונת פרודקשיון, זה לא רעיון טוב לעשות את התהליך הזה ולא לבדוק אף פעם אם הוא אכן עובד, עד לאותו יום שבו איזושהיא קריסה תסתיים בזה שהמערכת לא תהיה זמינה גם אחרי העלייה. קונפיגורציה מהסוג הזה מחייבת קביעת זמן מתאים מבחינת העולם שמסביב לבדיקה ולניסוי. זה קצת משעמם אולי, אבל זה חלק הכרחי ממלאכתו של אדמין).

Saturday, September 19, 2009

forwarding your email from unix

this is a quick and dirty post, as I'm trying to document an issue which should always be taken care of, but as it is not an issue that requires a lot of maintenance, it is also easily forgotten. so now there will be a documentation, of sorts, for the future: 

introduction: the why
When creating a backup routine for a unix/linux machine it is important to remember to check the logs. If we used crontab, the results of any problematic run will be emailed to the cron-run-owner/root account (respectively).

Therefore, if we are talking about a server/another machine whose root email is not methodically inspected (horrible practice, but i've encountered it in too many occasions), a simple solution is to forward the email to another account (which catches two birds in one strike, also solving the importance of reviewing root's email1) 

how do we forward ? 
for any user that is not root, create at the user home directory a file called .forward, and inside type the email to which the mail address should be forward. 

in many systems this solution will also work for root. in others, the mail configuration (permissions, etc) shall prevent the .forward file in root's home directory to be read by the mail services. in that case, the solution is simple: 
1. add to /etc/aliases an alias for root, in the format of: 
root: email@emailservice.com
2. and then run newaliases for root 

further reading 




[last update:31/12/2013] 

Sunday, February 15, 2009

The COBOL programmer and Y2K

Personal circumstances will take me away from this blog for a while. A leave of sorts for good reasons, which reminded me of an old joke. It is always nice to depart with a joke, wouldn't you agree?
"The year is 1998 and a COBOL programmer gets sick with all of the bug 2000 work he has to do. 
Worse than the boring work, he knows that if everything works fine, nobody will thank him, but if there will be a slight problem - it is his fault !
So he thinks about it, and decides to use a cryogenic service, to freeze himself for several years, and plans to wake up 10 years later, well into the new millennium.  
He enters the cryo-machine, and feels like no time had passed at all when the machine is re-opened. Outside, a room full of people are celebrating and cheering around him, as he comes out of the machine. 
"Whats up ?" he asks the person nearest the machine. "Is 2000 passed already ?" 
"Yep!" he is answered, "this is 9999". 
"How did so much time pass ?" he asks. 
"There was a dating bug in your freezing machine, and so you remained frozen for all this time". 
"Why all the celebrations ?" he asks. 
"Well, you see, the year 10000 is nearing, and it seems all sorts of software systems aren't compatible." 
"And ?" he asks, though he knows the answer. 
"And you are the only person on earth who knows COBOL".

I received this joke in my INBOX many years ago, while I was working on Bug 2000.  I could not trace its origin, despite efforts, and therefore cannot credit the person who wrote it. You can find  a similar version on the following computing joke collections -