IT manager open position (90% Linux)
*Please* *send cvs to **shavit.ma...@biscience.com saying - recommendation from David Ronkin.** * *Luck!* * * *Primary responsibilities for role**:* The IT Manager The will be responsible for managing and leading the entire IT department and activities in the company including IT and operations employees with emphasis over: · Production implementation planning, scheduling and development of associated implementation processes, managing all aspects of primarily Linux servers on which web applications and databases are hosted. · Performing functions such as analyzing, coordinating and/or assisting with resolution of customer impacted system/servers problem. • Monitor daily operation of server environment. • Performing server maintenance including tuning, capacity planning and forecasting, Monitoring server alerts, working with the engineering and RD team to assist in change control Implementation and version roll out on company’s product line. · Operational assistance to company’s key departments – Marketing, Sales, Product and RD. · Office helpdesk – Responsibility for office helpdesk environment including local office server network health, helpdesk, local backups and hardware. * * · Management of Office Active directory, domain controller, group policy and Exchange. * * · Working with senior management to propose, agree and deliver IT service to defined Service Level Agreements. · Full Responsibility for the provision of IT infrastructure services including desktop applications, Local and / or Wide area networks, IT security and telecommunications. *Requirements* Expert Linux administration experience (server builds, upgrades, patches, clustering, user policies, scripting, system configurations etc.). Experience with multiple Linux distributions and FreeBSD are required. · Web server technologies (Apache, Lighttpd, SSL, etc.) maintaining and configuring Apache/Lighttpd Web server and MySQL databases, hardware troubleshooting skills and RAID/hardware configurations. · Extensive Knowledge in LAMP environment administration. Experience with server virtualizations in Linux/Windows. * * · Experience in networking and protocols in Linux/Windows environments. · Develop automation and process shell scripts via SH/BASH/PHP/PERL to perform Application server administration tasks, including creation of scripts for alerts to provide Maximum availability. • Extensive experience with SMTP, SNMP, Postfix, DNS, FTP, and the ability to write procedures, general system administration documentation. 5+ years experience in a datacenter environment in support of Linux systems Essential knowledge and an extensive experience of 7+ years in the fields: · Linux oLinux – Extensive administration skills of different distributions (Linux/Redhat/FreeBSD) oWeb Services administration - Lighttpd, Apache, PHP and MySQL. oScripting: Bash, Perl and PHP. oMonitoring – Nagios, Cacti, Zabbix, MRTG oProtocols – OpenVPN, PPTP, BGP, TCP/IP, HTTP, SSL oFirewall/IPTables administration · Windows oActive Directory, domains, group policy and Exchange. oWindows XP - Windows 8 experience in helpdesk and troubleshooting. oFirewall administration *General * oHigh level of English, Quick learning abilities, very good people communication skills, highly organized and methodological o24/7 Availability – a must oExperience with SQL – Advantage. oExperience with customer technical support – Advantage. -- בברכה, דוד רונקין *נא בקרו בבלוג של*י: http://dronkin.blogspot.com *הערוץ של מאיר*: http://www.youtube.com/user/ronkinim ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
c/unix q
hello using the usual pipe()+fork()+dup()+close() to fork a child process and pipe data from and to it, I know both the child and parent must close the unused fds. why ? what if i don't close the unsed fds ? thanks, erez. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: c/unix q
Nothing. You're just wasting resources (file descriptors) and making your code a bit harder to understand and maintain. Note that for pipe(), you can use both fds at both ends of the pipe, but it's very easy to get into a race condition.Better to open a pair of pipes, one for each direction (of course, you now need to worry about deadlocks...). Rony On Tue, Jun 4, 2013 at 2:24 PM, Erez D erez0...@gmail.com wrote: hello using the usual pipe()+fork()+dup()+close() to fork a child process and pipe data from and to it, I know both the child and parent must close the unused fds. why ? what if i don't close the unsed fds ? thanks, erez. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- Ubi dubium, ibi libertas (where there is doubt, there is freedom) ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: c/unix q
On 06/04/2013 02:43 PM, ronys wrote: Nothing. You're just wasting resources (file descriptors) and making your code a bit harder to understand and maintain. It kind of says to anyone reading the code that you put the minimum into creating it you could, and implies there are details that were not addressed. Of course I'm an old assembly language programmer, where everything is declared, nothing is left to default, and anything allocated or opened is explicitly freed or closed when you are done with it. Geoff. -- Geoffrey S. Mendelson, N3OWJ/4X1GM/KBUH7245/KBUW5379 It's Spring here in Jerusalem!!! ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: c/unix q
Bt. Wrong. If the unused side of the pipe is left open by the process which doesn't read it then it will be considered as open even if the other side closed it, therefore preventing the reading process from receiving the EOF mark (read(2) returning zero bytes). And just to backup my claim above - see a more comprehensive response here: http://stackoverflow.com/a/976087 On 4 June 2013 21:43, ronys ro...@gmx.net wrote: Nothing. You're just wasting resources (file descriptors) and making your code a bit harder to understand and maintain. Note that for pipe(), you can use both fds at both ends of the pipe, but it's very easy to get into a race condition.Better to open a pair of pipes, one for each direction (of course, you now need to worry about deadlocks...). Rony On Tue, Jun 4, 2013 at 2:24 PM, Erez D erez0...@gmail.com wrote: hello using the usual pipe()+fork()+dup()+close() to fork a child process and pipe data from and to it, I know both the child and parent must close the unused fds. why ? what if i don't close the unsed fds ? thanks, erez. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- Ubi dubium, ibi libertas (where there is doubt, there is freedom) ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- [image: View my profile on LinkedIn] http://www.linkedin.com/in/gliderflyer ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: c/unix q
On 4 June 2013 21:43, ronys ro...@gmx.net wrote: Nothing. You're just wasting resources (file descriptors) and making your code a bit harder to understand and maintain. Note that for pipe(), you can use both fds at both ends of the pipe, but it's very easy to get into a race condition.Better to open a pair of pipes, one for each direction (of course, you now need to worry about deadlocks...). And about this one (race conditions) - any two processes using pipes (which have limited buffer size) to talk to each other bi-directionally run the risk of a deadlock if not coded carefully since they can easily reach a point where both of them block on write(2) which will only unblock when the other side read(2)'s and frees up space in the buffer (but the other side is blocked on a write - that's why it's called a deadlock). Typical ways to avoid that are to create threads to watch the fd's or use none-blocking IO. Rony On Tue, Jun 4, 2013 at 2:24 PM, Erez D erez0...@gmail.com wrote: hello using the usual pipe()+fork()+dup()+close() to fork a child process and pipe data from and to it, I know both the child and parent must close the unused fds. why ? what if i don't close the unsed fds ? thanks, erez. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- Ubi dubium, ibi libertas (where there is doubt, there is freedom) ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- [image: View my profile on LinkedIn] http://www.linkedin.com/in/gliderflyer ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: c/unix q
thanks, so i guess if i use unidirectional connection, and the reader does not expect to get an EOF() thank i'm safe. thanks, erez. On Tue, Jun 4, 2013 at 3:23 PM, Amos Shapira amos.shap...@gmail.com wrote: On 4 June 2013 21:43, ronys ro...@gmx.net wrote: Nothing. You're just wasting resources (file descriptors) and making your code a bit harder to understand and maintain. Note that for pipe(), you can use both fds at both ends of the pipe, but it's very easy to get into a race condition.Better to open a pair of pipes, one for each direction (of course, you now need to worry about deadlocks...). And about this one (race conditions) - any two processes using pipes (which have limited buffer size) to talk to each other bi-directionally run the risk of a deadlock if not coded carefully since they can easily reach a point where both of them block on write(2) which will only unblock when the other side read(2)'s and frees up space in the buffer (but the other side is blocked on a write - that's why it's called a deadlock). Typical ways to avoid that are to create threads to watch the fd's or use none-blocking IO. Rony On Tue, Jun 4, 2013 at 2:24 PM, Erez D erez0...@gmail.com wrote: hello using the usual pipe()+fork()+dup()+close() to fork a child process and pipe data from and to it, I know both the child and parent must close the unused fds. why ? what if i don't close the unsed fds ? thanks, erez. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- Ubi dubium, ibi libertas (where there is doubt, there is freedom) ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- [image: View my profile on LinkedIn] http://www.linkedin.com/in/gliderflyer ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: c/unix q
ְAlso, you might cause other software that inherits the fds to fail/complain/whatever. I only mention this because just yesterday I noticed that when running 'lvs' on my Debian wheeze laptop, I get: File descriptor 3 (/usr/share/bash-completion/completions) leaked on lvs invocation. Parent PID 11833: -su File descriptor 4 (/usr/share/bash-completion/completions) leaked on lvs invocation. Parent PID 11833: -su File descriptor 5 (/usr/share/bash-completion/completions) leaked on lvs invocation. Parent PID 11833: -su and when I searched I found: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432986 FYI -- Didi 2013/6/4 Geoffrey S. Mendelson geoffreymendel...@gmail.com On 06/04/2013 02:43 PM, ronys wrote: Nothing. You're just wasting resources (file descriptors) and making your code a bit harder to understand and maintain. It kind of says to anyone reading the code that you put the minimum into creating it you could, and implies there are details that were not addressed. Of course I'm an old assembly language programmer, where everything is declared, nothing is left to default, and anything allocated or opened is explicitly freed or closed when you are done with it. Geoff. -- Geoffrey S. Mendelson, N3OWJ/4X1GM/KBUH7245/KBUW5379 It's Spring here in Jerusalem!!! ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: c/unix q
On 04/06/13 15:28, Erez D wrote: thanks, so i guess if i use unidirectional connection, and the reader does not expect to get an EOF() thank i'm safe. Why are you so keen on doing it wrong? No, you are not safe. If the child process dies because of a segmentation fault (or whatever), the parent will notice this through the EOF received (I am assuming here, since you couldn't be bothered with closing a file descriptor, that you did not install a SIGCHLD handler to monitor for this possibility). This means that should one process die unexpectedly, the other will hang forever. Best practices are there for a reason, despite what others here might have you think. Shachar ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
